你想想 20 年前是什么样子的生活，然后你能想象出 20 年后的生活吗？

数据库，github 上开源直接导入进去就行

无所谓，干净整洁就行了

从具体的问题入手吧。
比如数据库索引采用 B 树会有什么问题改成 B+有什么效果。很多 hashmap 冲突时为什么会链表转红黑树。
每个面试官并不一样，但是都不希望你在背理论，能结合问题把技术的演进过程串起来就非常不错了。

业务多规则判断可以写成责任链

他想要的应该是 binlog

分页，带上上一次的游标

@dengji85 本身属于确定性的参数，就应该显示传

我这边的方案是获取登录态信息只在 controller 层处理，往下层走的时候以方法参数的形式传过去。
具体的流程是：
1. 网关获取请求头中的 token，登录态 filter 解析 token （ isLogin，uid，uname，merchantId ）设置到请求头。
2. 网关带着登录态请求头转发请求。
3. 底层服务从来不需要关注登录态，直接获取请求头即可。

服务端扛不住的，后台下发 token 直传 oss 吧

@baiyi go 夜读挺不错的，我经常在 b 站看夜读视频

可以看看书，这些都是常规知识点并不算卷，可能面试官提问方式太直接了没有引导话语，导致你有点紧张。

还是蛮重要的 ，比如不了解索引机制你怎么优化 sql 呢？

@timi +1，直接模版生成拼接好就行了

这样的话还搞啥微服务，一张宽表聚合了事😂

为什么会有坏人

@mlcq 这个就是写扩散的问题，微信朋友有上限这个问题在可控规模

@securityCoding 更新操作有误。应该是不用管直接更新即可

@bemyself
第三题这种问题其实挺好的 ，说说我的想法。
从 feed 流方向来考虑设计方案，一般而言会有两种模式：
1. 推模式，容易写扩散
2. 拉模式，容易读扩散

微信朋友是双向关系且数量有上限不会无限写扩散可以考虑使用推模式，朋友圈是时间流倒叙。

下面分析一下信息流所有者的操作场景：
1.写，每次发信息流广播给所有的朋友，每个朋友会有一个自己的 message box，读取朋友圈只需查询自己的 messageBox
2.删除，删除信息流即可，messageBox 不用删除，因为查询时无法命中
3.更新，同删除
4.拉黑，查询信息流时校验关系过滤即可
5.查询，结合旁路缓存策略提高性能
6.查询自己的朋友圈，直接查询自己的 message box 即可，详情有缓存机制。

还有一些细节，比如点赞、评论采用常规思路就行了。