简单说说数据分片和数据库部署方案

一、数据分片
1.数据分片的目的
    默认我们当前都知道，数据复制只能提高数据的读并发操作能力，并不能改善数据写操作的并发能力及整个存储容量。所以如果当业务中对写操作也有大量的并发需求需要满足，又或者数据表特别大，那么此时单一的服务器就可能并不能很好的实现我们的需求。怎么办呢？数据分片。
    
2.数据分片是什么
    其实就像听起来的一样，数据分片就是讲一张数据表切分成较小的片，然后再将不同的片存储到不同的服务器上面，这些服务器之间互相独立，每台无服务只存储一部分数据，查询时SQL语句通过分片键访问特定的服务器。
    分片的方法有两种，分为水平切分和垂直切分。
    1）水平切分
    通过对字段的筛选等方式将表横向切分，切分后的表结构不发生变化。
    如：根据SEX字段水平切分为两张表，一张存储SEX字段为‘男‘的数据，另一张存为‘女’的。
    2）垂直切分
    垂直切分又分为垂直分库和垂直分表。
        ·垂直分库
        指按照业务将关联性高的表进行分类，然后分布到不同的数据库上面。
        ·垂直分表
        对应水平切分，就是将表进行拆分。往往当某表中字段太多影响查询速度时，就使用这种手段将不常用的字段与常用的字段拆分开。
    
3.数据分片的实现
    1）硬编码
        很简单，假设我们有两个服务器，然后将表根据比如字段SEX进行计算，如果是‘男’则连接到服务器1     进行写操作，如果是‘女’则连接到服务器2进行存储。
        但这样带来的问题很多，虽然男女比例不均衡的问题可以通过改善为更为平均的识别字段的方式规避，     但主要的问题在于分片逻辑不应由程序自身实现，这样高耦合的做法原则上是不利于程序的维护和扩展         的。所以我们可以将这种映射关系存储在外面。
   
    2）外部存储
    即程序在进行SQL操作的时候，通过查询外部存储来获得自己应当连接的服务器编号等信息，并根据获得的信息连接相应的服务器进行操作。
    
4.数据分片面临的问题
    1）需要大量额外代码
    2）难以置信多分片联合查询（几乎不可能）
    3）无法使用事务
    4）难以扩展
    
    不过还好，现在已经诞生了不少专业的分布式数据库中间件解决上述的问题，例如Mycat就是几乎透明化的一个中间件。
    至于难以扩展的问题，主要矛盾点在引入更多服务器后分片规则需要改变，并且分片规则变更后往往原本服务器的数据也需要进行迁移，这是比较麻烦的事情。现在在实践中常用的方法是在项目伊始就使用逻辑数据库，意即在逻辑上将数据库切分为多个逻辑数据库，这样未来扩展时也就省去了很多麻烦。
    
二、数据库部署方案
    1.单一服务和单一数据库
    最简单也是最早的通用部署方案，在用户量比较低时的架构方法。即一个或多个应用服务器完成单一的功能，通过负载均衡向外提供服务，而它们统一连接一台单一的数据库服务器。
    
    2.主从复制
    依然是单一服务，但数据库采用一主多从方案。关于一主多从等关于主从复制的概念不明白的可以看上一篇文章。
    
    3.双web服务及双数据库
    双数据库即上面提到的垂直分库操作，基于业务功能对数据库进行分割，对应的服务器集群也需要分为两个，这样做一般会让系统的耦合度变得很低。
    
    4.综合部署方案
    即综合前面的方案，一个简单的例子：实现垂直分库后，双web服务中某一个的写操作压力很大，就可以对其所对应的数据库继续进行分片操作，同时每个分片数据库也可以（最好是）使用主从复制。
    
    当然，如果并不是非要使用传统的关系型数据库，你也可以考虑NoSQL数据库，因为NoSQL数据库会提供更为强大的数据存储和并发读写能力。然而因为CAP原理的约束，NoSQL往往可能遇到无法保证最终一致性的问题，这时候就需要通过时间戳合并、客户端判断或者投票等一种或几种方式进行解决，此处就先不做赘述了。