这两天一直在出差，在高铁上突然想起一些东西，先做个记录吧。
数据库的能力不是无限的，针对一些特别的高需求的应用往往需要在集成架构和应用架构上去做些优化，从而满足应用的需求。数据库厂商也在努力提升产品的能力，尽可能从数据库的角度来满足应用的需求。不过数据库产品的能力总是有上限的，不可能满足应用的所有需求。
第一个场景是0数据丢失，在传统的数据库灾备环境中，RPO为0是绝大多数系统的追求。0数据丢失十分有价值，虽然某些应用系统允许少量数据丢失。
不过数据库层面能保证RPO为0，对于应用来说是最为友好的。早些年阿里的支付宝在使用ORACLE 9i的时候，就创造性地使用了一种通过写REDO远程副本的方式实现了同城灾备系统中RPO为0。这种技术目前还在ORACLE ADG的同城灾备中使用。这种方案的实现比O记自身提供的FAR SYNC更为简单实用，在某些场景中也更加有效。
第二种场景是极致高可用。大多数应用对于高可用的目标要低一些，早期ORACLE OPS/RAC就实现了分钟级的TAF切换，通过FCF可以实现秒钟级的切换。对于大多数应用场景而言，哪怕是银行核心交易，医院HIS系统等，分钟级故障切换已经能够满足高可用切换要求了，当然监管部门对此提出了更高的要求，因此这方面的追求是无止境的
。而对于证券交易，期货交易，电网调度等系统而言，可用性的要求更为极致。数据库哪怕再安全都无法给这些系统提供足够的可用性保障。因此这些系统都可用性不能完全依靠数据库系统，应用本身能够短时间脱离数据库来完成交易撮合是十分关键点。
如果没有这方面的能力，交易系统是无法满足期货交易这样严苛的可用性要求的。十多年前我给移动的短信平台做系统优化，就发现有一家供应商的系统可以脱离数据库运行30分钟左右，而另外一家只要数据库挂了系统就挂了。这就是应用架构产生的可用性差异。
第三个场景是极致高并发。极致就是只你可能不大想象得出来的QPS，高到很可能超出单体数据库的能力极限。这个场景最初是互联网场景。当单体数据库无法搞定的时候，首先我们会做分库，如果分库还解决不了，那么就分表。比较幸运的是这种场景的写入或者查询都相对简单，因此分库分表的实现对于应用来说还算可控。
分布式数据库最初就是用来解决这些场景的，对于一些超高并发的简单场景能给予很好的支撑。不过数据库厂商的野心在不断扩大，他们希望分布式数据库不仅仅能解决简单的业务，也能解决复杂度业务场景。不过到目前为止，分布式数据库还没有表现出对复杂的机制高并发场景的完全把控能力，因此针对这样的场景，应用及应用架构上的优化依然十分重要。
