公众号：杨建荣的学习笔记 · 发布：2019-01-02 23:59:55 · 原文链接

这是学习笔记的第 1847篇文章

新年第一天，可谓是忙得热火朝天。手里头堆积了一大堆的事情，很多算是累计跨年的遗留事项。

对于数据库方向的熔断机制，今年需要考虑一下，之前碰到了一个紧急的问题，是数据库连接溢出，这种情况比较尴尬的是一旦出现问题，管理员都没有机会登录进数据库。这种情况就好比一个公交车挤成了沙丁鱼罐头，结果司机挤不进去了。对于这方面的改进，可以从几个维度来进行细化：

1. 新版本的数据库建议打开extra-port，在危机时刻，这个技巧可以算是救命技巧，毕竟一上来就是重启数据库显得太粗暴了。

2. 已有的5.5数据库要考虑升级到5.7了，5.7算是一个相对稳定的版本，升级会带来统一的维护成本和新特性统一管理

之前总结了一个优化案例 Oracle性能排查小案例，当时感觉还算是比较简单，没想到简单总结以后写出来，发现大家喜欢看这类文章。 后面尽可能多的使用案例的文章形式。这个案例随后的一个跟进版本比较有意思，因为做了系统优化之后，在周日的时候还是有应用卡住的情况，所以这个问题还没有治本，需要把之前的报告都认真的读一遍，看看能不能找到更多的细节和有价值的信息，一个初步的方向是锁，确切的说是死锁。这一块的分析可以好好cook一下。

关于任务调度的设计和改进，今天有两点感受，一个是我对任务调度的任务分解有一个相对清晰的认识，但是一直没有把这些体系很细致的描述出来，导致在任务的分工和协作中，大家有些模糊，而我以为大家都理解了，所以这一块是我需要继续补充和改进的。

另外在任务调度方向，目前碰到了一些有挑战的问题，也是目前的任务调度系统的一些通用问题。

问题简单描述起来就是对于API的调用超时会直接闪断，还有对于任务的并发控制不够，会导致部分应用系统压力过大而崩溃，这些都是在之前测试功能的部分时没有发现的，而后续要接入更多的业务，这些问题解决不掉就很尴尬了。

而对于周期性数据的清理，目前设计了一个较为完整的体系，那就是采用

[db]_arch和[db]_future的设计来完成周期表的管理和维护，直接听起来不大容易理解。

如果一个数据库中存在大量的表需要定时清理，是基于日期维度或者其他业务维度，我们可以先把表数据暂时保留，而把表置为不可见，这样从业务层面就是对表做了清理，而实际上如果后续发现问题也可以及时进行回滚。

这里的[db]_arch就是一个回收站，表信息不会真的删掉，而是直接移动到了这个归档库，而[db]_future的数据库则是存放未来生效的表，比如我们需要生成100张表，可以提前创建或者是找一个合适的时间在线生成，显然，这种操作是存在风险的，比如在线创建的时候表结构信息不满足需求，或者是在线创建的表结构信息难以进行确认，通过[db]_future可以做到缓冲的目的。

这套体系要完整的贯穿起来，其实对于数据库的drop类操作就是一大法宝。