如何使用wp做网站,h5特效网站欣赏,图列说明网站开发的流程,wordpress 多网址一、数据库架构原则高可用高性能可扩展一致性二、常见的架构方案方案一#xff1a;主备架构#xff0c;只有主库提供读写服务#xff0c;备库冗余作故障转移用jdbc:mysql://vip:3306/xxdb高可用分析#xff1a;高可用#xff0c;主库挂了#xff0c;keepalive(只是一种工…一、数据库架构原则高可用高性能可扩展一致性二、常见的架构方案方案一主备架构只有主库提供读写服务备库冗余作故障转移用jdbc:mysql://vip:3306/xxdb高可用分析高可用主库挂了keepalive(只是一种工具)会自动切换到备库。这个过程对业务层是透明的无需修改代码或配置。高性能分析读写都操作主库很容易产生瓶颈。大部分互联网应用读多写少读会先成为瓶颈进而影响写性能。另外备库只是单纯的备份资源利用率50%这点方案二可解决。一致性分析读写都操作主库不存在数据一致性问题。扩展性分析无法通过加从库来扩展读性能。可落地分析两点影响落地使用。第一性能一般这点可以通过建立高效的索引和引入缓存来增加读性能进而提高性能。这也是通用的方案。第二扩展性差这点可以通过分库分表来扩展。方案二双主架构两个主库同时提供服务负载均衡jdbc:mysql://vip:3306/xxdb高可用分析高可用一个主库挂了不影响另一台主库提供服务。这个过程对业务层是透明的无需修改代码或配置。高性能分析读写性能相比于方案一都得到提升提升一倍。一致性分析存在数据一致性问题。请看一致性解决方案。扩展性分析当然可以扩展成三主循环但不建议(会多一层数据同步这样同步的时间会更长)。如果非得在数据库架构层面扩展的话扩展为方案四。可落地分析两点影响落地使用。第一数据一致性问题一致性解决方案可解决问题。第二主键冲突问题ID统一地由分布式ID生成服务来生成可解决问题。方案三主从架构一主多从读写分离jdbc:mysql://master-ip:3306/xxdbjdbc:mysql://slave1-ip:3306/xxdbjdbc:mysql://slave2-ip:3306/xxdb高可用分析主库单点从库高可用。一旦主库挂了写服务也就无法提供。高性能分析大部分互联网应用读多写少读会先成为瓶颈进而影响整体性能。读的性能提高了整体性能也提高了。另外主库可以不用索引线上从库和线下从库也可以建立不同的索引(线上从库如果有多个还是要建立相同的索引不然得不偿失线下从库是平时开发人员排查线上问题时查的库可以建更多的索引)。一致性分析存在数据一致性问题。请看一致性解决方案。扩展性分析可以通过加从库来扩展读性能进而提高整体性能。(带来的问题是从库越多需要从主库拉取binlog日志的端就越多进而影响主库的性能并且数据同步完成的时间也会更长。建议不要分多层且一台主库一般挂3-5台从库吧。一般配置的mysql并发最好控制在2000/s挂5台的话整体基本能支撑1w/s的并发再加上缓存和二八定律基本能支撑小10w/s的并发很高了。如果还不能满足需求那还是选择去分库吧。)可落地分析两点影响落地使用。第一数据一致性问题一致性解决方案可解决问题。第二主库单点问题暂时没想到很好的解决方案(这点评论里给了一种方案可参考)。注思考一个问题一台从库挂了会怎样读写分离之读的负载均衡策略怎么容错方案四双主主从架构看似完美的方案jdbc:mysql://vip:3306/xxdbjdbc:mysql://slave1-ip:3306/xxdbjdbc:mysql://slave2-ip:3306/xxdb高可用分析高可用。高性能分析高性能。一致性分析存在数据一致性问题。请看一致性解决方案。扩展性分析可以通过加从库来扩展读性能进而提高整体性能。(带来的问题同方案二)可落地分析同方案二但数据同步又多了一层数据延迟更严重。三、一致性解决方案第一类主库和从库一致性解决方案注图中圈出的是数据同步的地方数据同步(MySQL主从复制简单来说就是从库从主库拉取binlog日志再执行一遍想深入了解可以去查阅“MySQL主从复制原理”相关资料)是需要时间的这个同步时间内主库和从库的数据会存在不一致的情况。如果同步过程中有读请求那么读到的就是从库中的老数据。如下图。既然知道了数据不一致性产生的原因有下面几个解决方案供参考直接忽略如果业务允许延时存在那么就不去管它。强制读主采用主备架构方案或者代码指定读主库(一般不建议这样就失去了读写分离的意义)读写都走主库。选择读主写操作时根据库表业务特征生成一个key放到Cache里并设置超时时间(大于等于主从数据同步时间)。读请求时同样的方式生成key先去查Cache再判断是否命中。若命中则读主库否则读从库。代价是多了一次缓存读写基本可以忽略。数据库中间件引入开源(mycat等)或自研的数据库中间层。个人理解思路同选择读主。数据库中间件的成本比较高并且还多引入了一层。第二类DB和缓存一致性解决方案先来看一下常用的缓存使用方式第一步淘汰缓存第二步写入数据库第三步读取缓存返回读取数据库第四步读取数据库后写入缓存。一般来说并发量不是特别大的话上面的方式就可以。但是如果是高并发量的情况下当写入时你淘汰了缓存但是还没写入数据库时或者主从延时就有一个读请求完成了此时缓存中就会缓存旧的数据。此时可以写库完成时等一会(根据业务场景评估)再删除一次缓存这样缓存旧数据的概率又低了不过这样一来数据库的压力就会有相应的增加并且响应时间会增加。其实要想保证数据库和缓存严格的一致性很难甚至要付出很高的代价。网上还个方案就是用本地内存队列来控制读请求和写请求串行化利弊都有感兴趣可深入研究高并发场景下如何保证缓存和数据库双写的一致性。另外思考一下是不是能用基于临时顺序节点的Zookeeper分布式锁(用两个锁一个读锁一个写锁当排在写锁后面的第一个读锁被通知时读操作完成后批量删除后面连续的读锁注意不要引发羊群效应 - 主备架构时)注设置缓存时一定要加上失效时间四、个人的一些见解1、架构演变架构演变一方案一 - 方案一分库分表架构演变二方案一 - 方案三 - 方案三分库分表架构演变三方案一 - 方案二 - 方案二分库分表注方案四一般不用。2、个人见解加缓存和索引是通用的提升数据库性能的方式分库分表带来的好处是巨大的但同样也会带来一些问题详见MySQL数据库之互联网常用分库分表方案。不管是主备分库分表还是主从读写分离分库分表都要考虑具体的业务场景。一般大部分的数据库架构还是采用方案一和方案一分库分表典型的读多写少的场景用方案三读写分离分库分表。另外阿里云提供的数据库云服务也都是主备方案要想主从读写分离需要二次架构。记住一句话不考虑业务场景的架构都是耍流氓。
