一起来聊聊数据库设计的思路和要点~

一起来聊聊数据库设计思路和要点吧~...



作者：zhangnian88123

转载自：

https://www.zybuluo.com/zhangnian88123/note/514000

解决单个数据表数据量太大的问题，将单个表的数据均匀的放入多个表中。

用于实现主从同步，主库的更新操作（insert/update/delete）向从库（1个或多个）进行同步，同步成功完成后主库和从库的数据是一致的，但是在同步过程的时间窗口内，主从数据是不一致的。根据userid或PK将SQL请求路由至正确的分片实例中，常见的路由策略有：

1、号段

算法：比如[1, 1kw]为一个分片，[1kw,2kw]为一个分片。
优点：实现简单，数据分布均匀
缺点：请求可能不均匀，比如有些业务场景下新增的用户请求量更大。

2、Hash

算法：Hash(userid) % 分片个数
优点：实现简单，数据分布均匀，请求分布均匀
缺点：新增分片需要迁移数据，可采用一致性Hash减少需要迁移的数据量

解决办法互联网应用的特点是绝大部分请求都是读请求，通过一主多从、冗余从库、读写分离的方式，通过增加从库数量，可以有效的提升读请求的性能和可靠性。主库只处理写请求，从库处理读请求。

存在问题：

1、写库是单点，无法保障高可用

2、主从同步需要时间，在这段同步的时间窗口内，读请求可能会读到旧数据解决办法一：双主通过冗余写库的方式实现写库的高可用，写库之间进行数据复制：

缺点：
1. 多个写库之间的同步容易出现冲突，从而导致同步失败或数据不一致，一般比较少采用这种方式。

解决办法二：主主同步 + Virtual IP通过VIP的方式，正常情况下读写都在其中一个主库上，同时主库向另一台备用主库同步数据，当这台主库宕机后，VIP浮动到备用主库，备用主库处理后续的读写请求。

优点：
1、对应用层透明，应用层只需通过VIP访问数据库即可

2、故障自动切换，当检测到主库故障时，VIP会自动浮动到备用主库上

缺点：
1、资源利用率只有50%

2、读写流量都落在主库上，没有通过从库的方式提高读性能解决办法一：冗余从库、读写分离解决办法二：缓存引入Cache后应用层的读写流程变为：

读流程：
1. 读Cache
2. 成功读到数据后直接返回，Cache Miss则读DB
3. 用从DB读到的数据去更新Cache

写流程：
1. 淘汰Cache
2. 更新DB

注意，这里在极端情况下，会出现读写一致性问题：写请求淘汰了Cache，但是还未更新DB成功，这时另一个读请求到来，读请求读Cache时Miss，从而去DB加载数据，而此时的数据还是旧数据，因为写流程中更新DB那一步骤还未完成，所以此时读请求读到的是旧数据，并且将旧数据也放入了Cache中，导致后续所有的读请求都读到旧数据，直到下一次写请求到来。

解决这个问题的办法有两种：
1. 为每个缓存项设置过期时间，过期时间到达之后该缓存项会失效，从而导致读请求穿透到DB，从而强制去DB加载一次最新数据。
2. 在写流程中增异步淘汰缓存的流程（双淘汰）：

写流程变为：
1. 淘汰Cache
2. 更新DB
3. 异步淘汰Cache，比如：利用定时器或定时队列，在60s后主动淘汰Cache，导致读请求穿透到DB去强制加载一次最新数据使用一主多从架构时，由于主从同步需要一段时间开销，因此在这段时间窗口内数据会不一致性，表现出来的现象就是应用层读不到刚才写入的数据。

解决办法：强制读主

引入一个数据访问中间件，将主从同步时间窗口内的请求路由到主库作为国内最受欢迎的架构师盛会，2016第八届中国系统架构师大会(SACC)将于2016年10月27日-29日在北京万达索菲特大酒店撼世来袭！

大会以"架构创新之路"为主题，共设置两个主场分享时段，24个技术交流专场时段；邀请来自互联网、电子商务、金融、电信、政府、行业协会等20多个领域，150多位技术专家及行业领袖来分享他们的经验；并将吸引4000多名系统运维、架构师、及各种企业的IT决策人士参会，为他们提供最具价值的交流平台。



点击“阅读原文”立即购票！

    关注 ITPUB技术社区