failover：失效切换或者热备份切换。FailOver是一种不可逆的从standy database 到primary database切换的过程

垂直切分：(vertical partition)：分库，把那些关系依赖非常紧密的数据保存在同一库。
水平切分(horizontal):分表。策略，a,轮询b,虚拟切片c,一致性hash算法

Scale Up:买更好的机器添加更多的资源来取得更好的性能.而形式上采用的是并行数据库、分布式数据库的模式，具体细节依赖水平分区或者垂直分区的技术
Scale out:主从配置（Master-Slave）、采用数据库复制（Replication）技术以及服务器的缓存（Server Cache）等，来将负载分布到多个物理节点上去

Sharding:Sharding 是把数据库Scale Out到多个物理节点上的一种有效的方式.Sharding可以简单定义为将大数据库分布到多个物理节点上的一个分区方案。每一个分区包含数据库的某一部分，称为一个shard，分区方式可以是任意的，并不局限于传统的水平分区和垂直分区。一个shard可以包含多个表的内容甚至可以包含多个数据库实例中的内容。每个shard被放置在一个数据库服务器上。一个数据库服务器可以处理一个或多个shard的数据。系统中需要有服务器进行查询路由转发，负责将查询转发到包含该查询所访问数据的shard或shards节点上去执行

sharding与partition区别
1，sharding分片是scaleout，每个节点尽量处理不同的查询。sharding所处理的应用一般只涉及到少数几个节点
partition分区将一个查询进行并行处理，这样所有的节点能并行处理一个查询。分布式数据库基本上每个查询都需要所有的节点参与，如果某些节点down掉后，系统会大受影响
2，分区一般只针对于一个数据库内部进行分割；而sharding可以以数据库为粒度进行分割，因此可用来构建多租房数据库系统（multi-tenantdatabase）



Sharding的优点


对于Sharding来说，主要有以下主要的优点：


（1）提高了数据库的可扩展性，可以随着应用的增长来增加更多的服务器，只需要将新增加的数据以及负载放到新加的服务器上就可以。
（2）提高了数据库的可用性。其中几个shard服务器down掉之后，并不会使整个系统对外停止服务，而只会影响到需要访问这几个shard服务器上的数据的用户
（3）小的数据库的查询压力比较小，查询更快，性能更好。
（4）系统有更好的可管理性。对系统的升级和配置可以按照shard一个一个来做，并不会对服务产生大的影响

Sharding可以轻松的将计算，存储，I/O并行分发到多台机器上，这样可以充分利用多台机器各种处理能力，同时可以避免单点失败，提供系统的可用性，进行很好的错误隔离。



MySQL5.1提供的分区(Partition)功能确实可以实现表的分区，但是这种分区是局限在单个数据库范围里的，它不能跨越服务器的限制。

Sharding与数据库分区(Partition)的区别
有的时候，Sharding 也被近似等同于水平分区(Horizontal Partitioning)，网上很多地方也用水平分区来指代 Sharding，但我个人认为二者之间实际上还是有区别的。的确，Sharding 的思想是从分区的思想而来，但数据库分区基本上是数据对象级别的处理，比如表和索引的分区，每个子数据集上能够有不同的物理存储属性，还是单个数据库范围内的操作，而 Sharding 是能够跨数据库，甚至跨越物理机器的。






备注:

从企业IT架构体系上来看，对于web2.0网站来说，必须考虑的就是可扩展性：随着使用人数的增多，能够及时的扩展IT系统的能力。解决这个问题，通常 有两种解决方式：Scale up和Scale out，两种扩容的方式分别从两个维度来解决数据库压力。所谓Scale up就是向上扩容，Scale out就是平面型的扩容。纵向的扩容就是将DB Server的配置提高，增加硬件配置，通过硬件速度提升来解决访问压力，横向扩容就是将应用的数据拆分，将原来集中存储的数据根据一定的规则分布到不同 的物理数据库服务器上。Up模式实施成本较高，大到一定压力之后，硬件可能无法满足这类需求。从web2.0网站来看，如果能够通过叠加相对廉价设备的方式实现存储和计算能力的扩展，是长期可扩展的有效手段，这点是Scale out所带来的优势
不过另外一方面，Scale out这种方式策略的制定复杂度以及维护成本要高于Scale up。采用Scale out这种方式，首先需要解决复杂的分布式计算的问题（相对来说Scale Up方案不需要考虑这个问题），这对于很多国内的web2.0网站的技术人员来说，是一个巨大的技术门槛；另外，Scale Out方案还需要对原先的软件进行大量的重写工作，以保证系统能在分布式服务器上运行（Scale Up方案则对现有软件几乎没有改动要求）；还有就是Scale Out方案始终面临着数据集中的问题，即拆分过的数据在服务器逻辑体系中仍然是各自相对集中的而非无限随意拆分。

"Share Nothing" 是从数据库集群中借用的概念，举例来说，有些类型的数据粒度之间就不是 "Share Nothing" 的，比如类似交易记录的历史表信息，如果一条记录中既包含卖家信息与买家信息，如果随着时间推移，买、卖家会分别与其它用户继续进行交易，这样不可避免的两个买卖家的信息会分布到不同的 Sharding DB 上，而这时如果针对买卖家查询，就会跨越更多的 Sharding ，开销就会比较大。
Sharding 并不是数据库扩展方案的银弹，也有其不适合的场景，比如处理事务型的应用就会非常复杂。对于跨不同DB的事务，很难保证完整性，得不偿失。所以，采用什么样的 Sharding 形式，不是生搬硬套的

===============================================================================================
这个replica set包括一个primary DB和多个secondary DBs。Primary DB由replica set中的所有servers，共同选举产生。当这个primaryDB server出错的时候，可以从replica set中重新选举一个新的primaryDB，从而避免了单点故障

.replication机制的优缺点：

优点：负载高时可以通过replication机制来提高读写的吞吐和性能

缺点：

首先它的有效很依赖于读操作的比例，Master往往会成为瓶颈所在，写操作需要顺序排队来执行，过载的话Master首先扛不住，Slaves的数据同步的延迟也可能比较大，而且会大大耗费CPU的计算能力，因为write操作在Master上执行以后还是需要在每台slave机器上都跑一次。

2.sharding技术

sharding技术可以弥补replication机制的缺点。因为sharding可以很好的扩展，我们知道每台机器无论配置多么好它都有自身的物理上限，所以当我们应用已经能触及或远远超出单台机器的某个上限的时候，我们惟有寻找别的机器的帮助或者继续升级的我们的硬件，但常见的方案还是横向扩展, 通过添加更多的机器来共同承担压力。我们还得考虑当我们的业务逻辑不断增长，我们的机器能不能通过线性增长就能满足需求？Sharding可以轻松的将计算，存储，I/O并行分发到多台机器上，这样可以充分利用多台机器各种处理能力，同时可以避免单点失败，提供系统的可用性，进行很好的错误隔离。

通过数据切分来提高网站性能，横向扩展数据层已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取（Read）数据的速度和并发量。目前国内的大型互联网应用中，大量的采用了这样的数据切分方
=================================================================================
高可用性（HA）与Replication机制
在分布式存储系统中为了保证数据的可用性可采用master-slave Replication机制（其中master只提供写服务，slave只提供读服务）