建一个联合索引 (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> 来处理消息.

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

@wuhaoecho 不是 go 比 java 多了指针, 而是 java 比 go 少了指针.

@NeoZephyr 麻烦解释一下 https://github.com/alibaba/fastjson/blob/436cae79bfb327f3641ac4c901e9411fc827b415/src/main/java/com/alibaba/fastjson/parser/JSONLexerBase.java#L41 这里的 ch,sp,bp,np 都是什么意思?

解 json 的代码和业务代码是一回事吗?

可以参考 线段树的懒标记 的做法

这个问题的关键点在你要怎么查,
如果只需要遍历, 那直接压缩了就行了.
如果要查就要考虑怎么做索引, 直接放文件系统只靠目录确定能查到吗?

@Triump 用 presignedGetObjectUrl