数据库集群只是看起来很完美，对企业来说很鸡肋。

       最近看到很多关于数据库的东西，因为数据库可以说和操作系统一样，很接近底层，是一个高技术含量的产品，很巧的是，越底层越核心，越接近技术的实质。
       今天总结一下，不管用的是哪一种数据库，数据库的目的或者说核心使命就是要安全存储和高效查询。各种数据库系统在安全存储方面做了一些努力，其中主要有备份，复制，镜像等，具体到每种不同的数据库，实现技术和名称叫法有差异，但都在这些范围之中。
       至于加密等等一些功能，不再讨论，因为这不是数据库要解决的核心问题。
       为了更高效的查询，各种数据库都不约而同的选择了终极性能解决方案，全内存处理，因此在这个地方，各种数据库都在尽量避开访问磁盘，即便要访问磁盘也要尽可能的少量。
       下面就再说说高可用和高性能方面的问题，高可用是容灾的，高性能是解决处理效率的。从各个高性能处理方案来看，除了磁盘可以通过一些手段来增强之外，内存的极限是没有办法突破的，必须通过硬件的改造升级。因此做多机的高性能集群，并不能解决单机系统的性能瓶颈，仅仅是做到了分流，提高了并发支持度，无助于提高单一事务的执行效率，因此，提高单一事务的执行效率只能从算法入手。这种情况下，建立集群，加入更多的节点，对提高性能是没有效果的。
       还有另外一个问题也是我们引入多机集群后，要考虑的问题，那就是多机部署后，查询缓存的命中率问题，多机的引入会不可避免的导致查询缓存刷新变慢，命中率变低，因为即便是集群环境下内存仍然是独立的，不能实现集群内共享，即便可以共享，通过网络IO的资源共享和内存的访问速率相比也根本没有可比性，此时引入多机也是不能解决问题的。
       在大多数情况下，尽可能的提高单机的性能是最有效的，高性能集群在数据库方面能提供的加强非常有限。仅仅对于高访问量来讲是有助力的，能分摊一些负载，但同时也增加了数据库层的复杂度，容易引入数据的不一致性，并会倍增写操作的资源占用（网络带宽，CPU时间，磁盘空间，冗余部分的处理过程会引入不可控因素），那么数据库的核心之一——“安全存储”就受到了挑战。
因此，在引入多机集群之前，请确认你需要这么做。
       目前比较好的高可用方案是复制和冷备相结合的方案，对集群概念倍加推崇，甚至觉得集群是终极完美方案的，大都是外行，在外行面前耍耍大刀还行，这些都是卖概念的家伙，不是真正能做事的人。集群适用的场景是有很多特定条件的，多数情况下生搬硬上集群不仅不能解决问题，还会带来系统复杂度提升的问题，系统复杂度的提升本身就等于成本的提升，这种升本不提效的搞法不是内行人所为。

       捧概念无异于捧臭脚，会去捧臭脚的人非坏即蠢，说到底是个人能力和素质的甚至人品的问题，浮躁的环境只是外因，做事情不能实事求是，是不适合做事情的，您如果专注作为数据库主服务器的配置和可靠性，并为您在它上面的跑的进程做好优化，大多数情况下问题就已经得到解决了，多机集群解决不了事务级别的任何问题，因为数据库是有状态的，这种必须考虑状态的情况，引入集群所能提升的性能极其有限。提升单机处理能力往往比堆叠集群更能直指问题的所在。果真达到了单机处理的极限，是否考虑集群仍然需要慎重选择，而常常可以通过增加缓存层，消息队列，异步处理方式很好的解决问题。

        集群是一个貌似万金油的方案，可惜，万金油方案常常是相当糟糕的方案，架构设计本身就是和业态契合的一种设计，千人千面，并没有一成不变的完美设计，也并没有万全良策。适合就是一种完美。不适合就是缺陷。适合某某大厂的架构设计也常常并不适合其他行业，甚至都不适合相同行业不同业务特点和规模的业态。听起来好听的”拿来主义，弯道超车“，看似聪明，看似付出少一点，但也注定获得少一点，投机而已，成不了事业。这种聪明实在蠢笨，不去下笨功夫，让自己聪明，耍这种聪明而得意洋洋，注定会像皇帝的新装一样可笑、可叹，可惜，可恨。

        现代的中国人很”聪明“，很会投机，投机也是赌的一种，这里有很多社会环境因素，使得大家太喜欢赚快钱了，这些社会因素不变，大多数人投机上瘾的习惯也不会变，这样的问题害人不浅，最坏的结果是投机不练功，荒废了一生，没有技术的踏实积累，我们甚至我们的后代可能都注定上不了高端台面，没有引领的可能，只能跟着让跟随的大哥。