怎么拯救一个不靠谱的业务系统数据库（4 如何解决问题之乱弹）

在上期出差后的感想打岔后，实际上第三篇的解决问题，在出差后的升华后，解决问题的思路突然打开了。

之前的想法是如何规范，如何按照数据库本身的特点来设计配合业务系统，但实际上如果你了解了上层的思路和“一些不为人知” 的“上流”想法后，就会对之前解决问题的想法有所动摇，或者有所宽容。

你是否遇到过一个马上要上线的系统，然后告诉你，没有优化，糟糕的和上次如出一辙，连程序员都告诉我，如果在接入多几家银行可能就崩溃了，好吧我们都知道，我想领导心里也有数。可为什么还是这样，是上层不懂， NO NO NO ,如果你还这样想估计段位还是不够。领导的心那是门清。why why why ?

这就得联系到上次第三篇的问题，如果你根本不知道业务，那你一定是回答不了这个问题，如果你能知道业务背后的事情，那你就不会惊奇，如此的事情会在一次次的warning后，还是如此。

你是否遇到过某些根本就不稳定的系统，要上线，为了某些业务需求，上也的上不上也得上，明知缺胳膊少腿，也要上，你必须要理解，必须要妥协，必须要懂得大局观。

举例，一个和外部沟通的系统，银行发送报文给你，你接受，进行快速处理，报文是JSON格式的，而还在用SQL SERVER 来让程序和程序员将定性和无法掌握规律的数据，都存进SQL SERVER的无厘头的搞笑做法，明知道MONGODB可以是好的选择，但问题是

1  那个程序员不会

2 业务着急上线，凑合一下，反正还不知道这个业务是死是活，动用那么多脑力和心力

3  这个业务本身就是要失败的

所以此时你不恰当的出现，给出一个看似正确的论调，实际上你没有看到背后的种种。此时你应该怎么解决问题，闭上嘴，弄清楚业务的需求方，以及业务的来龙去脉，弄清楚这个业务是短命鬼，还是长命百岁，在稍微的给出“正确”的调调，才是解决问题的正常状态。

当然写到这里，估计技术型的“咖”，已经想骂人了。我们只负责技术，管你后面乱七八糟的东西。

那就画风转转，先论论到底怎么在发现问题后，拯救的问题

1  举例，一个业务系统的历史成型比较复杂，并且在初始状态下并没有良好的设计，将所有的数据都在一个数据库（物理）上成型，我想这是不少中小公司的状态，因为请不到或者根本就没有请架构师，或者当初做这个工作的时候根本就不知道能不能成功，一个初期凑合的系统，若后期业务稳定了，大概率数据量上来不出性能问题那是不可能的。 

解决的手段这里来 speak up一下

1  拆分法：多个应用使用一个物理库的情况下，很多人的做法是提高系统的物理水平，增加CPU ，增加内存，增加磁盘的读写能力， 当然这一时是可以能将问题掩盖住，可后期如果还是往这一个库上堆叠，复杂的业务逻辑和数据，早晚纵向的扩展方式有无能为力的一天，那时我建议你，还是跑路吧，烂摊子你是收拾不了的。

所以你的个建议是在堵住“窟窿”后，马上告知此物理库无法在容纳继续要添加的应用和数据，让设计人员另起炉灶。将部分业务和逻辑抽离出这个数据库，从根本上限制恶性循环。

2 扩展法：弄清楚业务逻辑，将与业务有关的数据保留在这个物理库，将和业务无关的系统数据迁出或加以限制，当然这需要程序和系统架构本身能进行扩展，能支持你这样的优化的方式，如果架构设计的本身就有众多的问题，可能扩展法的功效就得大打折扣。不过如果这个逻辑能通，那业务数据和系统本身的数据分离，则会往好的方向移步。

3  并行法：将业务细分，系统中同样的业务但服务对象不同，可以进行分离的，将这样的业务拆出来，另起炉灶将数据重新导向到其他新的系统中，这样也能缓解系统性能的问题。

4   缓冲法：出现性能问题，一定是某个时间段并发数据量过大，而系统处理出现问题，导致数据库无法承受，那就在出现问题的点，通过程序的缓存，或者添加REDIS ，或者MONGODB 数据库，将需要处理数据暂时缓冲，也就是类似于游乐园平时排队，和节假日排队等候区的设置一样。当然这样设置整体运行的时间一定会更长，不过系统由于过载报警的问题就消失了。

   

实际上根本的还是一个初靠谱的设计，就不会出现上面的问题，（可这在大部分单位早期大多都不会具备条件，但后期一个成熟的单位应该重视前期的架构设计和技术部署，要不连招聘的时候，应聘的人员一句话问到你系统的当前状态，你都不好意思正面回答，高手听到当前的状态就知道你有前途还是没前途了），低级的数据库优化手段，例如添加索引，整理碎片，分区表，分库分表，读写分离，冷热数据分离，数据双写等等也是解决性能问题的手段，不过前期设计不好，部分手段也是亡羊补牢和无力回天。

所以遇到trash 系统，还是先从根本上了解相关的为什么会产生这样的情况，然后在考虑如何对症下药，数据库不是垃圾系统的 trash bin.