本文通过一个观察者模式的故障案例，介绍了如何解决因瞬时大流量导致的消息丢失问题，并探讨了重启观察者、调整消息长度限制及使用gperftools检测内存泄露等解决方案。
1.重启观察者
有一天告警发不出去了，然后重启了一下就好了，为啥呢？程序A有很多观察者，程序B是程序A的一个观察者.突然由于A给B发送的一次消息超过了2M，处于安全的考虑，程序A将程序B这个观察者踢出观察队列，导致程序B不能正常收到程序A发来的消息，这一次B发给A的所有消息都丢失了，B也不工作了，这时候消息丢了，找不回来了，用户的诉求是：消息可以不找回了，但是接下来的消息必须不能丢失了，于是重新启动了B程序，将其注册为A程序的观察者，这样就又正常工作了，暂时解决了问题。但是后续的突发大流量消息还可能会导致这样的异常出现，于是将A发给B的瞬时最大长度调整成4M，这样可以避免一些瞬时大流量导致的程序不工作。
2.日志可视化
3.日志可视化ELK
4.tcpdump源码分析
5.gperftools
go里面的pprof 太好用了，c++ 这个gperftools是对应的。
6.字节序的写法
7.EOF到底是什么？
8.系统级别的性能分析工具
9.centos下安装vscode
10.告警系统设计
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
