作者存档: boear

闲鱼里淘二手商品的一点感悟

最近玩航模玩的有点越陷越深了,钱包感觉压力山大啊,无奈打起了二手商品的主意,毕竟航模圈子还是蛮大的,而且各种装备更新换代也很快的,各个二手交易平台都有大量的二手航模装备出售。

说到二手交易平台,国内影响力最大的还得说是闲鱼,毕竟是阿里集团马爸爸一手培养起来的交易平台,不过不知道是出于什么目的,目前的闲鱼仅能通过APP进行访问,从淘宝二手的入口变的越来越鸡肋,即便从淘宝里搜到了闲鱼里的商品,在淘宝的电脑端是完全不能进行任何操作的,这一点弄的有点让人匪夷所思,不知道是出于什么考虑。

另外要说的就是闲里卖商品的商家了,为什么要说是商家呢?因为目前闲鱼里大量出售物品的已经不是个人出售闲置物品了,而是各种的职业商家,而且还有大量的商品是会直接跳转到淘宝页面的,特别是那些标注了『全新』标签的商品,很大机率点开就会直接跳到淘宝APP里。

接下来我们就说说这些所谓的商家,闲鱼里的商家大约会这么几类

第一类是个人卖家,出售一些闲置物品,这也是闲鱼对外宣传的定位,这类卖家一般都比较实在,或者说是叫天真,商家各种的拍照片,商品描述非常详细,出售的商品一般都是质优价廉,碰到这样的卖家会是一次非常愉快的购物体验,不过现在的闲鱼里这样的卖家已经越来越稀有了。 继续阅读 »

阿里云竟然可以无耻到这个地步

今天无意中又看到了上个月发的文章,就登陆上阿里云帐户,看了一下提现功能是不是升级完成了,结果自然不出所料,还在升级中,让提交工单进行人工处理。

手贱又提交了一次提现申请的工单,又是漫长的沟通过程,最后基本实锤了,想提现到支付宝就不用想了。充值时说好的提现规则直接就被他们以保护客户资金安全为理由完全推翻了。所谓的系统升级只是一个借口而已,阿里云已经打算直接关闭掉除了原路退还以外的所有提现渠道。

我说每次提交工单的时候,为什么总是想法设法的引导客户走原路退还流程,原来是早就计划好的,只是一个缓兵之计而已。

前几天还看新闻说阿里今年的财报不太好看,想着应该跟自己没什么关系吧,想不到会以这种形式对自己产生影响。

从大学毕业开始就一直是阿里的铁粉,坚持尝试阿里家的各种云产品,没想到最后得到了这么大一份回报。

你服务器越用越慢,我认了,毕竟你们也要赚钱,服务器超卖点也可以理解。

然后强制升级配置,每次升级价格就上升一档我也不说啥了,毕竟配置确实是高了那么一丢丢。

内置监控程序,对用户进行进行监控,我也不说啥了,毕竟我又没做什么违法的东西,不怕你们审查。

现在又把主意打到了用户资金上了,这就有点不厚道了吧,明摆着是在割老用户的韭菜吧。 继续阅读 »

在四轴的坑里越陷越沉:第二架战机正式服役留念

真是人算不如天算,一场突如其来的疫情将所有的计划全部打乱了,同时也带来了这辈子最长的一个假期,在家里憋的实在太无聊,还好有年前入手的小四轴可以玩,慢慢的算是入了门了吧,一些基础的飞行操作算是基本掌握了,可以比较自如的控制着这架小飞机在家里各个角落里来回穿梭了。

怎奈家里房子实在太小,可以飞的空间实在是比较有限,而且这小家伙还有一定的杀伤力,家里老婆孩子都在,实在是有些不安全,索性就拿着去楼下的草地上去玩了。

到了广阔的大自然才发现这架小四轴是多么的渺小,稍微飞远一些就已经看不清飞机的方位了,更糟糕是的一阵风过来,感觉随时都要坠机的样子。看来这小家伙还是只适合在室内玩,要在户外玩,有必要升级一下装备了。

有了前面小四轴的的实践经验,以及最近一段时间爬网站的理论储备,在万能的淘宝上采购回来各种配件,我的第二架四轴战机就正式诞生了。

继续阅读 »

Nginx正则相关的参数及规则

最近帮客户配置服务器,经常修改Nginx的配置文件,频繁的用到正式匹配规则,这里整理了一些常用的正则参数及规则,以备查询。

Nginx配置中Location的语法规则 location [ = | ~ | ~* | ^~ | !~ | !~* ] /uri/{ … }

= 表示精确匹配
~ 表示区分大小写正则匹配
~* 表示不区分大小写正则匹配
^~ 表示URI以某个常规字符串开头
!~ 表示区分大小写正则不匹配
!~* 表示不区分大小写正则不匹配
/ 通用匹配,任何请求都会匹配到
匹配顺序

多个location配置的情况下匹配顺序为:

首先匹配 =
其次匹配 ^~
其次是按文件中顺序的正则匹配
最后是交给 / 通用匹配
当有匹配成功时候,停止匹配,按当前匹配规则处理请求。 继续阅读 »

对Nginx缓存服务器进行大文件限速以改善用户体验

过去很长一段时间一直认为在服务器端对用户进行访问限速会使用户的浏览体验变差,是一种负优化,直到最近才发现对用户进行合理的限速也能改善用户的访问体验。

事情还要从一个多月前说起,在例行进行服务器检查的时候,发现几台Nginx缓存服务器的带宽波动非常大,经常短时间内顶满带宽,然后又降回到非常低的水平,害的我强迫症都犯了,到底要不要增加带宽呢?不增加的话,带宽顶满对用户体验来说肯定是会有影响的,但如果增加了带宽,一半以上的时间带宽使用率又非常的低,显然老板不会同意。

还是先从日志入手吧,随手翻了翻几台缓存服务器的日志,基本可以确定带宽顶满的时候是在进行视频文件的请求,经过上一次的教训,现在所有的视频文件都是从缓存服务器上直接读取缓存文件的,每个视频文件大小基本都在30-50M之间的样子,倒也不算太大,但访问量上去了以后的带宽占用情况还是比较可观的,就算每台服务器平均有5个视频连接并发,按目前顶满带宽的情况下,每个请求差不多只要5-10秒的样子才能完全下载完成。

但项目上用到的视频又不多,大部分的时间其实是没有视频文件的请求的,但一旦有视频文件的请求,哪怕是只有一个请求,由于视频文件偏大,还是会在短时间内把带宽顶到满的,这就造成了部分用户访问项目出现忽快忽慢的情况。

问题原因找到了,解决起来也就简单了,因为大部分视频文件的时长都在1分钟以上,并不是所有的用户都会耐心的把完整的视频都看完,所以完全没有必要让用户在几秒的时间将完整的视频下载到本地,只要能让视频保证流畅播放就可以了。 继续阅读 »