这是一个创建于 1446 天前的主题，其中的信息可能已经有所发展或是发生改变。
嗯，我自己写完，感觉也是，只有高并发的业务。。。
第 1 条附言 2022 年 2 月 5 日
嗯，谢谢，学习了
那么问下，是否执行完一个业务操作后，会主动埋个点，譬如注册后，主动发布一个注册的消息
不管现在有没有对应的后续操作，这样可以避免将来需要注册后发邮件之类的操作时对注册那边的逻辑的修改
那么问下，是否执行完一个业务操作后，会主动埋个点，譬如注册后，主动发布一个注册的消息
不管现在有没有对应的后续操作，这样可以避免将来需要注册后发邮件之类的操作时对注册那边的逻辑的修改
 | 1 sadfQED2 2022 年 2 月 5 日 via Android  1 延时消费，定时任务触发，异步消费，各种回调 |
 | 2 gabon 2022 年 2 月 5 日 via iPhone 1 同步处理某个业务之后异步修改其它数据是挺常见的业务场景吧，我们这边用 mq 解耦非常多，可能是因为业务是基础数据吧。很多下游需要监听消息修改自己业务逻辑。 |
 | 3 ClericPy 2022 年 2 月 5 日 1 不一定高并发吧... 三个场景任何一个匹配上都可以用, 以前还见过 feed 流直接拿 kafka 搞的, 跑的也好好的 |
 | 4 koloonps 2022 年 2 月 5 日 我用来调用局域网的服务 |
 | 5 abigeater 2022 年 2 月 5 日 1 异步消费的业务使用了，但领导最近嫌弃 MQ 想要改掉（未知原因 不过目前写了那么多服务，反而用了 MQ 的服务很稳定，其他的时不时就崩溃了（还是未知原因 |
| 6 ClericPy 2022 年 2 月 5 日 补充 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 |
Select Language