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

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

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

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

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

看监控大盘

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

二分?

@fh74599 小+肉 ，我二胎出来后开雷凌想死的心都有

不要买雷凌，不要买雷凌。

看国产车，开车 /乘车体验能上两个级别。

@liudaolunhuibl 也不全是，薪资倒挂正常的狠。老人带新人结果新人比老人薪资高多了的事也很常见

做过短信服务器后台，负责任的说投诉很有用，运营商接到投诉立马会对服务商进行核查处理，严重违规直接封通道的。

汉吧 ,坐过一次,很高级 233

@owne HR 就是压你薪资的 , 不满意直接拒掉就行咯

有个公字表示这个公开的密钥

我面试的时候喜欢问场景问题，循循渐进交互聊天

一般都要

carlife 是个垃圾，直接手机支架吧

换 ， 命要紧

dubbo 可以选用多种注册中心
1. redis
2. zookeeper
3.直连

参考文档 https://dubbo.apache.org/zh/docs/v2.7/user/examples/explicit-target/

记住一点 aof 是写操作命令记录，重写 aof 也是重放所有 kv 的写操作命令而已。期间除了 fork 子进程瞬间操作外不会阻塞 io 线程。

1. fork 进程重写 aof
2. 不能阻塞 io 线程，此时会通过 cow 将写操作记录到缓冲区
3.aof 重写完成时再追加写入期间的写操作记录
4.完成替换