分布式存储数据库
当只有单机mysql时，随着业务量的增大，非常影响数据库的性能。
为了提高性能，必须使用分库分表和主从数据库、读写分离的方案。
分库分表可以降低数据库B树的层次，便于快速的查找。
从你描述的场景来看，你需要在主机写入之后，保证在备机一定能够读取到已经写入的数据，也就是说，
你需要主从架构下的强一致性。
主机与备机之间的物理延迟是不可控的，也是无法避免的。但是如果仅仅需要满足这种强一致性，是相对
简单的事：只需要在主机写入时，确认更新已经同步到备机之后，再返回写操作成功即可。主流数据库均
支持这种完全的同步模式。已经有人提到MySQL的Semisync功能（从MySQL
5.6开始官方支持，此前的版本可以考虑Google出的非官方补丁），就是基于这种原理。
不过，一般不建议使用这种同步模式。显而易见，如果写操作必须等待更新同步完成，肯定会极大地影响
性能，除非你不在乎性能。
问题的关键在于，主从架构是一种用于数据容错的高可用性解决方案，而不是一种处理高并发压力的解决
方案。它的目的是主机当机以后备机可以马上顶上，而不是让备机来分担并发压力。完全同步机制也只是
用于保证主机当机以后数据不会丢失，而不是保证从备机读取数据时的一致性。因此，我根本也不主张你
使用从备机读取数据以分担并发压力这种方式。
解决方式是，不要试图在数据库层解决并发的读操作问题，至少不要在主从架构的数据库层解决。要在数
据库层之上架构一个redis这样的分布式缓存来解决，它是专门干这个的。其性能肯定远高于从备机读取数
据。
分布式缓存也存在着一些限制，例如不能完全支持事务处理。这取决于你的应用场景。对于一般的互联网
应用，并发压力大但不要求支持事务，可以考虑分布式缓存。对于银行这样严格要求强一致性的应用，对
于写入延迟一般没什么要求（延迟几个小时都可以接受，数据不出错就行），可以适用完全同步的模式。
主从数据库同步的过程
复制的基本过程如下：
- Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
- Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置；
- Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”；
- Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。
修改mysql代码涉及对开源库的掌控能力和对mysql代码修改能力的限制。
