@S2Line 你的理解很到位, 写好软件就是要控制好复杂度. 不过实际工作中很少有人能平衡好对内和对外的复杂度, 这也是我大力推荐 <软件设计哲学> 这本书的原因.

@chevalier #19 几年前读过他写的 <代码整洁之道>, 确实写得通俗易懂, 一条条都分得很细, 很适合刚开始写代码的时候读, 一直照着做应该能养成不错的编码习惯.

@yurong333333 #20 这本也算是经典老书了, 确实是一本很讲究实操的书. 很适合翻个大概, 然后像你说的那样, 用到的时候就查一下.

@happypy1 #18 <数据密集型应用设计> 去年刚看过这本, 确实是本好书. 很适合刚开始做大数据, 但选型时拿不定主意的时候看. 可以对大数据各个方面有个全局性的概览.

@ttgo #16 说到巨厚的书, 我大学也买过一本 <C# 高级编程> 全书 1200 页, 翻到最后发现还有一半内容因为写不下, 请看随书光盘, 我当时人都傻了 ಠ_ಠ

@littlewing 这本书可太经典了, 至今记得其中对于紧凑性的描述, 可以灵活运用于工作中, 检测大部分工作能否顺利完成. 不过这本书比较厚, 适合慢慢读.

@leishi1313 看起来是一份更加细化的 API 设计文档, 感谢分享.

@luban 多谢提醒, 正好我有京东会员.

@adoal 真巧, 这本 <发布！设计与部署稳定的分布式系统> 我们老板最近也向我推荐过, 看来过年在家要读读看.

@DuDuDu0o0 确实, 平时工作中很容易陷入到各种具体实现和细节当中, 适当地退一步思考和学习反而容易把思路理顺.

猜测省掉一次 group 会不会好一点? 不过我没数据也不好试, 写出来大概是这样.

select
SUM(lt300) as lt300,
SUM(gt300) as gt300
from (
select
IF(SUM(gold) < 300, 1, 0) as lt300,
IF(SUM(gold) < 300, 0, 1) as gt300
from `table_name`
where `time` > 1640966400 and `time` <= 1642176000
group by `uid`
) as `tmp`

API 设计的时候就要考虑好升级时的兼容性, 如果是破坏性升级就得版本号 +1, 然后调用方自行决定是否升级.
每次升级都要使用者全改一遍一般很难维护下去.

别在意, 逛论坛就得自带脑内过滤器, 把无建设性意见的帖子自动忽略掉.

有固定的分享机制对团队很有好处, 你们应该更进一步, 每周不同人分享, 而不是光一个人.
不用怕浪费时间, 每周五下午 2~4 点开会, 4~6 点分享聊天. 我们这么搞四五年了也没见耽误什么事.

@brader 我们用的也是阿里云的 RDS, 一般复杂的查询只是会慢一点, 但 CPU 消耗还好.
只有出现高并发写入的时候才会把 CPU 跑满.
你把每个任务的连接池最大连接数降到 1~2 个试试看, 然后直接把结果写成 CSV 用 LOAD DATA 应该会好一点.

有可能处理的时候并发数开高了? 一般单线程很难把数据库跑满的.
数据库核心数, 内存大小最好也说下.

@shyangs 要不是工作需要, 我碰都不想碰淘宝的坑爹 API.
有些状态码根本对不上, 明明不能重试的错误, sub_code 里写个稍后再试.
还有接口为了偷懒, 返回值里直接找个文本字段, 各种 JSON 字符串往里面塞, 传不同的参数, 这个字段里返回的数据格式都不一样, 全靠自己摸索.
还有各种乱七八糟的情况, 明显是规范覆盖的不全面, 维护接口的几代人各自有各自想法, 越整越乱.

@lanlanye 很高兴帮到你, 我们现在是用的阿里云 SLS 做 logstore 可靠性和性能都很不错.

至于"事件源架构"这套架构模式是几年前听一个国外大牛在上海做演讲时了解的.
如果想深入研究这套架构的话, 可以从这些文章入手:
https://www.infoq.cn/article/zC4O4tA8QYOHIMJXddSs
https://docs.microsoft.com/zh-cn/azure/architecture/patterns/event-sourcing

@lanlanye 写半天忘记回答 28 楼的提问了, 惭愧 XD. 因为冷数据的更新频率不是很高, 所以可以在 RDS 删除前确认下最后一次的事件, 如果开始写冷存储后有新的事件就这条数据就不冷了, 也就不用从 RDS 里删除, 这时是不需要加锁的.

@lanlanye 我之前回复有一搭没一搭的没能把这事讲清楚, 不好意思啊. 这次完整描述下, 看能不能把逻辑理顺.

先假设有一个简单的论坛系统, 基本操作只有发帖, 回复, 删帖.

设计表结构的时候也就三张表 users, posts, replys.

posts 里的 user_id 是指向 users 的外键约束.
reply 里的 post_id 是指向 posts 的外键约束.
刚开始因为数据规模不大, 级联删除可以打开.

实现业务逻辑的时候, 以发帖为例:
1. 首先开一个数据库事务.
2. 往数据库里插一条数据, 拿到自动生成的主键 ID.
3. 往 logstore 里写一条事件 {"action": "post:create", "user_id": "xxx", "post_id": "<ID>", "content": ""}.
4. 提交事务. (任意一步失败, 回滚事务)

删帖和发回复也是类似的流程.

此时如果要撤销删帖, 只要把之前与该贴相关的, 直到删帖前的事件重放一遍就可以.

后来论坛流量大了, 需要把长时间无回复, 无更新的贴子及里面的回复视为冷数据 (不是用户删掉的帖子, 用户删掉的帖子直接从 RDS 删除就好), 从 RDS 里去掉, 放在冷存储中.

这时候可以跑一个定时任务, 在每天低峰期的时候, 分批将 RDS 中不活跃的数据找到, encode 成 JSON 存入 MongoDB 或者 OSS 这类冷存储中, 并从数据库中删除.
JSON 格式大概这样: {"id": "123", "user_id": "xxx", "create_time": "2021-02-02T00:00:00Z", "content": "xxx", "replys": [...]}

之后如果有用户要查看冷数据, 可以从冷存储直接查, 必要的时候也可以写回 RDS.

这样设计的好处是, logstore 里的 events 作为整个系统唯一真实数据来源, 自带了审计日志的功能, 并且如果之后要切新数据库, 也只要写个新的消费者把 events 重放一遍就可以了.

当然限于篇幅有很多东西还是没法展开, 比如如何提高事件重放的效率, 如何保证消费时的幂等性, 如何在 RDS 中保留归档数据的元信息等. 这些如果遇到具体场景的话可以再设计对应的方案.

希望这次能讲的比较清楚, 若发现疏漏也欢迎指出.