@brader 如果屏蔽词是用 ac 自动机的话, 可以给当前状态加一个深度, 就能精确地判断哪些部分是绝对安全, 哪些部分是不确定的.

收 10 个字, 全检查一下, 没问题返回前 5 个, 剩下 5 个, 然后再等到有 10 个字的时候再检查, 再根据情况把 10,5 这 2 个数字调整一下不就好了.

经典八股文之《进程间的通信方式》 , 里面随便挑一种就行.

为什么要把编译的时间也算进去?

如果是公司的业务, 充钱可以让你变强.

建一个联合索引 (user_id, create_time) , 这样 user_id = 10 order by create_time 就可以直接利用索引.

虽然是一样的, sq.size == batchSize 还是写 sq.size >= batchSize 看着安心一点.

@James369 这是一个比较典型的一对多的场景, 通常做法可以是分成 2 个表, 第一个表就是不含 int 的表, 第二个表是 primary key + flag 的一对多关系, 查询的时候 join2 个表即可, 这样做可以在添加 flag 的时候不用 ddl, 如果 flag 类型很多, 也能用上索引. 一对多这个模型在很多 ORM 里面的文档里就有, 可以直接用对应的接口.

当然有些公司对 join 很恐惧, 不让用也是有可能的.

btree index 肯定是不行的, 因为你这种用法本质就是一个性能更好的 array, 只能用倒排索引. 最好想个其他办法.

@xuanbg 比方说我有个地方要算库存预计什么时候销售完, 你给我个负数, 这是不是就有 bug 了?

@xuanbg 那就来讲讲业务, 库存是电商的一个非常核心的功能, 和仓储, 物流, 财务, 运营, 采购这些都有密切相关, 库存不可靠的话, 你要全公司一起来兼容你的 bug 吗?

讨论技术问题就只讨论技术, 为什么总有懂哥来个什么程序员思维, 产品设计.
电商允许不一致, 那要是哪天你去做银行的项目, 遇到相似的场景, 也允许不一致吗?

精确的 count distinct 是没救的, 试试 hyperloglog 插件吧.

龟速乘

支付系统不是只要照抄支付宝 /微信的文档里写的做法就行了吗? 好像也不怎么要用到锁吧.

一般 A join B 可以拆成。select A, select B where id in (....); 然后用个哈希表去组合.
看你的描述是数据库设计的不好, 为什么不直接把数据库改好呢?

看了点代码, 感觉完全不行, 泛型这些就不说了.

algorithm: 冒泡排序之类的完全没用, 可以直接删了, QuickSort 也没处理最坏情况下 O(n^2), 字符串搜索留一个 BM 就够了,
二分查找通常分成 lower_bound 和 upper_bound, 没找到完全相同的返回-1 不是很好用.

bloomfilter: 你对 bloomfilter 的理解有问题, 建议重写.

cache: 我没看错的话, 除了接口更少,更不标准, 这个一个普通的 map 有什么区别? 一般来说, cache 自己都会带一个 evict 机制吧.

web 开发里会下面这个就足够了

lock.acquire()
do sth
lock.release()

会用到什么 2-3 个锁套来套去, cas 之类, 先看看是不是自己的设计有问题.

给每个消息加个 id, 由客户端控制 id 是什么, 服务器原样返回, 这样客户端就有办法拿到每次请求的上下文了.
这样客户端可以用一个 map<id, closure function> 来处理消息.

当然根据我的经验, 要改早改了, 客户端十有八九搞不懂怎么写异步通信, 建议跑路.