嗯,我自己写完,感觉也是,只有高并发的业务。。。
1
sadfQED2 2022-02-05 16:33:56 +08:00 via Android 1
延时消费,定时任务触发,异步消费,各种回调
|
2
gabon 2022-02-05 16:57:52 +08:00 via iPhone 1
同步处理某个业务之后异步修改其它数据是挺常见的业务场景吧,我们这边用 mq 解耦非常多,可能是因为业务是基础数据吧。很多下游需要监听消息修改自己业务逻辑。
|
3
ClericPy 2022-02-05 17:24:00 +08:00 1
不一定高并发吧... 三个场景任何一个匹配上都可以用, 以前还见过 feed 流直接拿 kafka 搞的, 跑的也好好的
|
4
koloonps 2022-02-05 19:30:08 +08:00
我用来调用局域网的服务
|
5
abigeater 2022-02-05 19:30:58 +08:00 1
异步消费的业务使用了,但领导最近嫌弃 MQ 想要改掉(未知原因
不过目前写了那么多服务,反而用了 MQ 的服务很稳定,其他的时不时就崩溃了(还是未知原因 |
6
ClericPy 2022-02-05 22:10:31 +08:00
补充 append 里的问题
1. 是否埋点跟着需求走, 但是日志一定要详细, access 日志, debug 日志 什么的尽量详细一点, 以后遇到问题或者有分析日志的需求(比如用户画像, 性能调优, A/B 测试, 版本迭代), 可以直接对接 ELK 做相关触发器以及可视化 2. 至于发送消息相关的看你是不是走事件驱动的架构, 如果是的话就发到消息中心里去, 一般情况下还是不要过早优化, 在没有基础设施的时候日志是预留扩展的比较简单的方式. 提前预留未来可能用到的接口是好习惯, 不过不要过度设计毕竟做了反而不会被表扬... 3. donnemartin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards. - https://github.com/donnemartin/system-design-primer |