[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/same-data-push.html
先粗略写，日后有缘完善
背景
上游系统在推送数据到下游系统时,由于网络、代码、又或者是运维上（主要是sql重推没去重之类的），导致上游短时间推送大量同一单号给到OMS系统，导致数据库压力剧增
[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/Hystrix-optimization.html
简述
本文说的其实就是
- 合理配置熔断，防止依赖的第三方接口响应过慢导致系统tomcat链接大量阻塞，最终导致系统崩溃的问题
- 顺便，将熔断配置从配置文件中提取出来，动态配置中心中，这样就可以通过动态配置中心来动态配置熔断参数了
- 除此，主要是团队里大家对
单线程并发数与QPS概念有些混淆且计算方式了解不多，以及信号量与线程池方案选择上有些歧义，需要花了不少时间在会议上让团队达成一致。
背景&分析问题
[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Bug-Log-Optimization/thread-pool-use-error.html
在生产环境中，我们遇到了一个由线程池配置错误导致的阻塞问题。本文将对这个问题进行详细分析，并提出相应的解决方案。
问题背景
[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Bug-Log-Optimization/cache-load-database-crash.html
背景
SISP自己基本不存储业务数据，但是每个节点都需要本地缓存了一些网点、员工信息、月结用户信息等基础数据，生产监控发现数据库定期压力飙升，数据库CPU压力到达80+%如图：
用脚趾头分析
[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Bug-Log-Optimization/database-skew.html
其实改动不是很大，这里简单记录下
背景
- OMS订单系统，日数据量较大平均近3kw/日,高峰达8kw+/日的订单需要存到数据库中（之前64库，现在扩到了128库）；
- 运维后台监控看到，各个库的压力不一，江浙沪，京津冀，深圳755等地区对应的数据库压力很高，而其他地区的数据库压力很低；
[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/ES-Query-Optimization.html
除此，还有一个比较好的优化，见： ES文档结构优化
背景
难得有数据留存,写一篇^_^
原逻辑
[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Bug-Log-Optimization/elasticJob-bug-fix.html
背景
刚进新公司3天正逢双十一，领导生产补数出问题了，
补数速度不稳定时快时慢，百万条数据补了好几个小时，之前都是几分钟搞定的，导致通了个宵；
早上我早到公司，领导截了个数据库的图给我，说交给我来看，然后刚通宵完的他就去开会汇报去了。。。我还没来得及熟悉环境，就被扔到了火坑里了，压力山大。。。
具体的过程没记录,这里只能凭回忆记录下了
问题描述
[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Bug-Log-Optimization/bug_in_spring-cloud_instance_registered_with_consul.html
优雅停机脚本见: shell-系统优雅停机
背景
公司实现微服务化并原来使用的Dubbo+Zookeeper实现应用间的服务调用，考虑到Dubbo不在维护最近想要切换为Spring Cloud+Consul