MySQL unique and Laravel soft delete

A UNIQUE index creates a constraint such that all values in the index must be distinct. An error occurs if you try to add a new row with a key value that matches an existing row. For all engines, a UNIQUE index permits multiple NULL values for columns that can contain NULL.

laravel 的 soft delete trait 使用 deleted_at 来作为约束。由于需要同时使用唯一和软删除两个特性,所以把 deleted_at 也作为 unique 的一个联合键。测试的时候发现,当 deleted_at 为 null 的时候,可以无限插入,unique并没有约束成功。MySQL官网描述如上,解决方案也容易,直接将 deleted_at 设置为 not null 即可

高并发下,获取最新评论

加入直播行业四个半月之后,终于接到一个有挑战活。

我司评论系统设计要求观众打开页面时,获取若干条最新历史评论。但是获取评论的地方有bug,获取评论会重复。

在解决这一Bug之后,我发现我们原有的评论逻辑会每隔5s缓存一次最新评论。这样做能减少服务器压力,但是在高并发的情况下,会造成大量丢失。请示大佬之后,大佬表示要达到数据一条不丢失的标准。

在简单研究之后,先将缓存逻辑改为:只要有新发评论,那么就让最新缓存失效,并让第一个请求数据的用户生成缓存。这样的话,用户取到的缓存永远都是最新的。

But!Naive!测试、分析之后发现,在我们现有前后端交互逻辑(下基本做不到数据不丢失(也可能是我太渣了)。下面是我画的我们现有逻辑的时序图(图1),图为高并发情况下,缓存失效时观众获取最新评论过程,图中省略的cache。在3~4步中,如果新插入数据超出了本页范围,那么新的数据将不会被取到。在5~7步消耗的时间中,用户有可能丢失上百条评论。

图1

分析上述交互逻辑,发现主要冲突在于获取最新数据和不断插入新数据之间的矛盾。那么调整下评论加载顺序,问题不就引刃而解了么!下图(图2)是调整后的交互逻辑:

图2

这里也有一点尴尬的地方:万一mqtt并没有收到消息,那么就需要使用上图1中 1~6的逻辑来获取评论了。。。

而更尴尬的是:咨询产品的大佬之后,产品表示这么高并发情况下,用户根本感受不到评论丢失,完全不用管,所以上面都是我在YY... T_T

群晖翻墙中转

家里的ps4是港服,一直想给ps搞个靠谱的代理方案。之前准备买个靠谱路由器刷梅林或者wrt搞,但是靠谱的并不是我这个小穷比现在承受的起的。。。

然后想起来家里还有一个群晖在跑,而且群晖还支持docker。。。

先到 docker hub 拉一个haproxy的镜像,然后还要ssh连上去写一个dockerfile,重新打包一个镜像。

群晖的docker套件不支持dockerfile build真是不人性啊。

最近也把想折腾的基本都折腾完了,搭了一个leanote,把所有该备份的都备份了一遍,ps4的翻墙也搞定了。该开开心心过年啦~