分布式开发之发布与订阅
发布订阅：数据实时备份同步
软件环境：sql server2008 r2
硬件环境：视数据量和对应机器分配的任务而定
机器数量：视分割线标准而定(即数据分别存放的分割线)
作 用 ：
- 数据库服务器出问题时我们也有其正常工作时的备份
- 一台服务器负载不起时，可以用来做负载均衡
- 数据库服务器可以无间断，无损失迁移
- 主服务器被攻击或当机时另一台服务同步机可以应急
意 义：咱们可以用于两台服务器，其中一台机器用作增删改，另外一台机器用作查询，为了防止读写分离(即发布订阅)的信息有分差，可以做出选择，即当前日期一周(时间视发布与订阅的日期而定，因为订阅是可自动设置时间的，如连续订阅或者在某一时间段订阅)以内的数据查询在发布的机器上运行，当前日期一周之前的数据在订阅机器上运行。
扩 展：
- 创建一个临时(发布)DB与一个分机(订阅)DB,当想数据库中insert数据的时候，插入到临时DB中，临时DB发布数据，分机DB订阅此数据(订阅的表可个根据表中的数据量波动而定，振幅小的无需订阅). 注：临时DB与所有分机DB中的除某些特定的表(振幅较大，发布的表)外，其他数据(元数据，如：issuetable, actiontable…)可以确保一致，以牺牲分机机器硬盘空间换取运行时的内存空间与效率.
- 以分机DB的ticket达到几百万或者发布订阅一年为分割线(分割线可根据具体情况而定),创建分机DB1。当分机DB1达到分割线时，创建分机DB2；当分机DB2达到分割线时，创建分机DB3……(若后续发现分机DB2分机DB1或者某几个机器的数据访问量并不大时，可将这些DB合多为1).当创建DB2时，可以将临时DB中与DB1中相同的数据删除(删除临时DB中被发布且已经被分机DB订阅的数据。注：若执行此方案，首先需要验证被删除的数据是否已经全部被订阅成功，其次发布订阅的实时性，在删除临时DB数据时，分机DB的数据是否也被删除，需要检查是否需要在执行该操作时，暂时取消发布订阅机制)
- 在数据库访问层进行配置数据库与表的对应关系，即在数据库访问层中根据需要操作的表的分割线决定数据在那个分机DB，而配置对应的连接字符串。
其 他：数据库分布式开发还有分库分表(Sharding)，Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。对于海量数据的数据库，可以使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个server上。如果每张表的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据库(server)上。
总 结：发布订阅相比Sharding，发布订阅是以牺牲物理存储空间来换取查询的执行速度，而且相比较而言，对于发布订阅可能维护的难度会更大。比如各个分机DB中的Metadata是重复的，若其中某一个表(IssueType)的某条数据的Name发生了改变，我们需要写脚本对所有的分机DB的name执行update(这里不对分机DB使用发布订阅来保证分机DB的metadata的统一，是因为如果分机DB过多没有办法保证它们的实时性。)。Sharding是根据某些表之间的关联进行分表分库，对于Metadata不会出现重复，各个库之间都是独立的数据，只是在查询的时候可能会join到多个数据库或者多个server，从而大大的降低了查询的效率。
|
|
发布与订阅 |
分库分表(Sharding) |
|
原理 |
牺牲物理存储空间来换取查询的执行速度 |
把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题 |
|
Metadata |
重复 |
不重复 |
|
维护难度 |
大 |
小 |
|
查询效率 |
高 |
低 |
|
Server之间的联系 |
小(各个机器上的数据是分开独立的) |
大 |
|
需要更改proc |
No |
Yes |
|
查询是否需要多台机器join |
if您看了这篇博客。对您有所帮助，请不要吝啬您的“推荐”，您的推荐将是我最大的动力。有问题的话可以评论交流。
本博客为原创博客，转载请注入出处