网站建设后期维护小魔仙,湖南建设银行官网网站首页,建设模板网站,店面设计流程戳蓝字“CSDN云计算”关注我们哦#xff01;作者#xff1a;尜尜人物来源#xff1a;https://www.cnblogs.com/littlecharacter/p/9084291.html一、数据库架构原则高可用高性能一致性扩展性二、常见的架构方案方案一#xff1a;主备架构#xff0c;只有主库提供读写服务作者尜尜人物来源https://www.cnblogs.com/littlecharacter/p/9084291.html一、数据库架构原则高可用高性能一致性扩展性二、常见的架构方案方案一主备架构只有主库提供读写服务备库冗余作故障转移用jdbc:mysql://vip:3306/xxdb1、高可用分析高可用主库挂了keepalive只是一种工具会自动切换到备库。这个过程对业务层是透明的无需修改代码或配置。2、高性能分析读写都操作主库很容易产生瓶颈。大部分互联网应用读多写少读会先成为瓶颈进而影响写性能。另外备库只是单纯的备份资源利用率50%这点方案二可解决。3、一致性分析读写都操作主库不存在数据一致性问题。4、扩展性分析无法通过加从库来扩展读性能进而提高整体性能。5、可落地分析两点影响落地使用。第一性能一般这点可以通过建立高效的索引和引入缓存来增加读性能进而提高性能。这也是通用的方案。第二扩展性差这点可以通过分库分表来扩展。方案二双主架构两个主库同时提供服务负载均衡 jdbc:mysql://vip:3306/xxdb1、高可用分析高可用一个主库挂了不影响另一台主库提供服务。这个过程对业务层是透明的无需修改代码或配置。2、高性能分析读写性能相比于方案一都得到提升提升一倍。3、一致性分析存在数据一致性问题。请看下面的一致性解决方案。4、扩展性分析当然可以扩展成三主循环但笔者不建议会多一层数据同步这样同步的时间会更长。如果非得在数据库架构层面扩展的话扩展为方案四。5、可落地分析两点影响落地使用。第一数据一致性问题一致性解决方案可解决问题。第二主键冲突问题ID统一地由分布式ID生成服务来生成可解决问题。方案三主从架构一主多从读写分离 jdbc:mysql://master-ip:3306/xxdb jdbc:mysql://slave1-ip:3306/xxdb jdbc:mysql://slave2-ip:3306/xxdb1、高可用分析主库单点从库高可用。一旦主库挂了写服务也就无法提供。2、高性能分析大部分互联网应用读多写少读会先成为瓶颈进而影响整体性能。读的性能提高了整体性能也提高了。另外主库可以不用索引线上从库和线下从库也可以建立不同的索引线上从库如果有多个还是要建立相同的索引不然得不偿失线下从库是平时开发人员排查线上问题时查的库可以建更多的索引。3、一致性分析存在数据一致性问题。请看下面介绍的一致性解决方案。4、扩展性分析可以通过加从库来扩展读性能进而提高整体性能。带来的问题是从库越多需要从主库拉取binlog日志的端就越多进而影响主库的性能并且数据同步完成的时间也会更长5、可落地分析两点影响落地使用。第一数据一致性问题一致性解决方案可解决问题。第二主库单点问题笔者暂时没想到很好的解决方案。注思考一个问题一台从库挂了会怎样读写分离之读的负载均衡策略怎么容错方案四双主主从架构看似完美的方案 jdbc:mysql://vip:3306/xxdb jdbc:mysql://slave1-ip:3306/xxdb jdbc:mysql://slave2-ip:3306/xxdb1、高可用分析高可用。2、高性能分析高性能。3、一致性分析存在数据一致性问题。请看一致性解决方案。4、扩展性分析可以通过加从库来扩展读性能进而提高整体性能。带来的问题同方案二5、可落地分析同方案二但数据同步又多了一层数据延迟更严重。三、一致性解决方案第一类主库和从库一致性解决方案注图中圈出的是数据同步的地方数据同步从库从主库拉取binlog日志再执行一遍是需要时间的这个同步时间内主库和从库的数据会存在不一致的情况。如果同步过程中有读请求那么读到的就是从库中的老数据。如下图。既然知道了数据不一致性产生的原因有下面几个解决方案供参考1、直接忽略如果业务允许延时存在那么就不去管它。2、强制读主采用主备架构方案读写都走主库。用缓存来扩展数据库读性能 。有一点需要知道如果缓存挂了可能会产生雪崩现象不过一般分布式缓存都是高可用的。3、选择读主写操作时根据库表业务特征生成一个key放到Cache里并设置超时时间大于等于主从数据同步时间。读请求时同样的方式生成key先去查Cache再判断是否命中。若命中则读主库否则读从库。代价是多了一次缓存读写基本可以忽略。4、半同步复制等主从同步完成写请求才返回。就是大家常说的“半同步复制”semi-sync。这可以利用数据库原生功能实现比较简单。代价是写请求时延增长吞吐量降低。5、数据库中间件引入开源mycat等或自研的数据库中间层。个人理解思路同选择读主。数据库中间件的成本比较高并且还多引入了一层。第二类DB和缓存一致性解决方案先来看一下常用的缓存使用方式第一步淘汰缓存第二步写入数据库第三步读取缓存返回读取数据库第四步读取数据库后写入缓存。注如果按照这种方式图一不会产生DB和缓存不一致问题图二会产生DB和缓存不一致问题即4.read先于3.sync执行。如果不做处理缓存里的数据可能一直是脏数据。解决方式如下注设置缓存时一定要加上失效时间以防延时淘汰缓存失败的情况四、个人的一些见解1、架构演变架构演变一方案一 - 方案一分库分表 - 方案二分库分表 - 方案四分库分表架构演变二方案一 - 方案一分库分表 - 方案三分库分表 - 方案四分库分表架构演变三方案一 - 方案二 - 方案四 - 方案四分库分表架构演变四方案一 - 方案三 - 方案四 - 方案四分库分表2、个人见解1、加缓存和索引是通用的提升数据库性能的方式2、分库分表带来的好处是巨大的但同样也会带来一些问题详见数据库之分库分表-垂直水平3、不管是主备分库分表还是主从读写分离分库分表都要考虑具体的业务场景。某8到家发展四年绝大部分的数据库架构还是采用方案一和方案一分库分表只有极少部分用方案三读写分离分库分表。另外阿里云提供的数据库云服务也都是主备方案要想主从读写分离需要二次架构。4、记住一句话不考虑业务场景的架构都是耍流氓。如果你是一个狂立学习flag却屡屡打脸的懒癌晚期或者是一个对云计算方面云里雾里不知所措的好学者亦或是一位资深行业专家都欢迎关注【CSDN云计算公众号】爆发自己学习的洪荒之力吧福利扫描添加小编微信备注“姓名公司职位”加入【云计算学习交流群】和志同道合的朋友们共同打卡学习推荐阅读一场全能的开发者大会来自助力开发者成功进阶的华为云抖音微博等短视频千万级高可用、高并发架构如何设计20大5G关键技术Fast.ai从零开始学深度学习 | 资源帖10个简单小窍门带你提高Python数据分析速度附代码程序员爬取 3 万条评论《长安十二时辰》槽点大揭秘暗网竟成比特币最大用户? 上半年5.15亿美元被用于非法活动真香朕在看了
