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

他想要的应该是 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 即可，详情有缓存机制。

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

高德非常喜欢走小路，被坑过导航到小巷子倒了半天才倒出来从此不再用高德了

看监控大盘

分两块来看？
1. 任务执行时间控制
可以看看分布式任务调度框架，基本都提供实时调整执行策略功能
2. 运行的具体任务
这个应该属于业务内部范畴了，可以通过任务调度框架传递上下文参数

二分?