“读写分离”技术实现、适用场景及典型路线解析.docx

《“读写分离”技术实现、适用场景及典型路线解析.docx》由会员分享，可在线阅读，更多相关《“读写分离”技术实现、适用场景及典型路线解析.docx（22页珍藏版）》请在优知文库上搜索。

1、1 .读写分离：概述1）何为读号分离读写分离，从字面理解就是将对数据库的读操作与写操作分离的一种优化手段.其最早起源于互联网快速发展时期，面对海H用户访问问题，通过这一技术来解决数据库性能瓶颈问题。目前已经成为非甫常见的一种数据库访问优化技术.2）读写分离好处提高访问性能通过引入读写分离技术，将之前集中于单点的访问压力，分散到更多节点.即可利用更多的资源，支撑业务系统，可有效提升整体访问性能.提高稳定性通过将读取与写入操作的分窝,可有效规避由于异常操作所带来的风险,常见如一个大查询语句，因访问数据规模巨大占用大量CPU资源.通过承载端分离，可避免影响更为重要的写入操作。提高资源利用率为了更好地

2、保护数据，数据库系统通常采用多副本技术冗余保护数据，但其备用副本如无法提供业务访问，将是一种资源浪费，而读写分商可有效利用只读副本，提升整体资源利用率。提高可用性通过引入更多节点来承载读写操作，结合负载均衡与高可用探苣技术，可避免单点故障引发可用性问题.提高访问效率通过利用不同节点分别承载读取与写入，还可缓解因为锁带来的争用问遗,提高单节点的访问效率.更大优化空间针对读取操作的特殊性，可通过分离后的独立资源采取特有的优化技术，进一步提升访问效率。2 .读写分离：技术实现1）常用方案目前业界流行的读写分离方案，通常都是基于上述主从模式的数据库架构，通过引入数据访问代理层，来实现访问动作的读写分离

3、。引入数据访问代理的好处是源程序不需要做任何改动就可以实现读写分陶，坏处是由于多了一层中间件做中转代理，性能上会有所下降，数据访问代理也容易成为性能瓶颈，并且还存在一定维护成本.还有另一种方式，是将数据访问代理层前者到应用侧,通过SDK方式与应用集成在一起，可避免独立一层所带来的性能损耗和维护成本高的问返.但这种方式对开发语言有一定要求，存在适用性问题.访问性能中高维护成本中低易用性高中开发语言不限受限代理方式SDK方式2）技术要点读写分题功能的好与不好，主要是在易用性和灵活度问题.前者是关心如何让业务开发像操作单个主库一样,无需过多关注主从读写分离的细节，只耗要做好相应读写配冒后，就无需考虑

4、写主读从的细节.后者是解决用户多变的业务场景和拓扑变化，并可实现自动适应。这其中是需要解决一系列技术问题,如下面这些常见的问题.判断读写攥作如何判断读写操作，是读写分离面临的首要问题.判断方式可大致分为自动和手动两种，前者是通过显式的方式由用户来指定；后者则是自动进行判断，用户无需关心.这两种判断方式往往是互补的，可配合来使用.下面是常见判断逻辅及处理：基于不同端口连接该实现方式就读写分离功能而言不是太好，因为此方式与应用自己实现没有明显差别，只是将直接连接不同数据库的逻相变成了连接中间件服务器的不同端口，并没有对应用系统开发带来实质性的简化工作。基于SQ1.匹配采用正则表达式匹配是比较容易实

5、现的方案，可以无需应用的修改，只需要在中间件添加正则匹配的规则，即可将读、写分发的逻辑在中间件完成.读写分离的效果，取决于中间件的正则匹配规则的编写质用。基于Hint应用系统发送SQ1.时，可以添加Hint,显示的告诉中间件想要将该SQ1.发送到何处。中间件解析特定规则的Hint,即可实现对带有不同Hint的语句分发到不同的数据库节点.基于语法解析当中间件获取到应用发送的SQ1.字符串时，对其进行完整的语法解析，可以最大程度的获取SQ1.字符串中的信息，例如类型、操作对象等。基于语法的判断，就能够自动针对不同语句类型进行读写分发，可以最大限度的减少应用的适配工作.茶口连接SQ1.匹配Hint语

6、法解析优点易实现应用无需改动应用控虫发应用无需改动M不荷化开发，与BS需配大量正则规应用需改造，有无法干预转发.用自壬实现无异则，漫作置杂，可改造成本活性稍差维IP性差使用语法解析是相对来说较为友好的方式，无需开发人员感知即可实现读写操作分离.但这其中存在难点，就是如何准确判断出只读操作存在一定困难，例如使用函数、存储过程、触发器或诸如SE1.EeT“.FORUPDATE”类的操作。此时，是需要引入辅助机制进行判断,可采取配置名单方式来辅助分析或者通过Hint、API的方式强制指定走写库或读库.除此之外，还有些命令也需要规范是否可在备由执行，如COPY、SHOW,SET.BEGINEND等.如

7、何处理事务事务类操作，往往藏味着数据变化,在读写分离中如何处理呢？通谓有两种思路，一种是简单粗基方式，将所有事务及关联操作全部发送到主机；一种是更为精确的处理，即分析事务内的语句序列，将事务中先写后读的对象进行关联，一起发送到主机，确保数据正确，而把和写操作无关的读操作，进行拆分，发送到备机执行.后一种处理方式能最大限度的利用读写分离，当然需要解决对象前后关系这一问颖.解决主笛延迟基于副本方式的延迟是常见的，也是读写分府在设计之初就需考虑的问题.其通常的处理思路可以有多种：强制读写走主席这类解决方案最简单粗品，也是实际工作中最常用的方案.通过对主备节点延迟情况的判断，来决定如何是走主库还是备库

8、.通常可将延迟判断封装在中间层，前端应用可不感知，只需配置延迟阈值即可，当超过这一阈值就自动走主库.如下次访问时延迟低于阈值，可更新走备库.当然，这一方式无疑会加大对主库的压力.轮转和电试备库当在备库读取不到最新数据时，另一种思路多读取几次或者尝试读取其他备库.这里面的核心是对读取最新数据的判断，通常需要在应用开发时有所考虑才可.同时还需要制定退化方案，在何种情况下退化到读取主阵.结合缓存解决如延迟是常态，很难短期内解决，通过引入缓存可达到立竿见影的效果.其原理是在数据写入主库时，同步或异步写入缓存，应用读取时优先读取缓存，失效时才读取数据库.这种方案因引入缓存组件稍显且杂，需解决缓存与数据库

9、同步更新及失效问期;同时对应用侧有一定影响,需感知到缓存.比较好的处理方式是都封装在中间层，通过它来统一处理访问逻辑。数据库优化展后一种就是尽见避免出现延迟，常见对数据库有些可优化的措施.例如尽量减少在主节点上执行大事务操作、减少主库索引进而减小写入开销、主备库采用不同存储引擎提升效率等等,当然这些方案只能起到一定作用，无法完全避免延迟问题.灵活负觑策Bg针对多个读库，读写分离组件还需提供灵活的负载均衡策略，常见的如随机、轮询、权生等等。这其中有几个特殊情况需要考虑：QoS不同读库的服务能力有所差异下，其能提供的服务保障不同，需在读写分题中提供例如权重的配首,进行干预。当然,更好的方式是提供服

10、务质量评估机制，可根据各读库的服务能力进行分配.位在总知针对多AZ、多Region的情况，不同读库承载的角色不同，有的只作为备选主库不承担读、有的作为远程灾备等，因此在读写分离中希望能感知到这些信息，有所区别对待.往往可通过设置标签的方式解决，根据不同标签设在不同策略. 解决读一致性在读写分离中，当存在多个读库下，会因为延迟不同，出现读取不一致的情况.即路由到不同的读库，读取的数据鲜活度不同。这对于前端应用会造成一定困扰，解决的方法可采用会话粘性的策略,针对同一会话路由到同一读席,避免出现读不一致. 拓扑结构感知如果读写分离访问的数据集群拓扑发生变化，例如主备发生切换，写操作要到新的主座；亦或

11、是增加了备旅数量，流量可以打到新备库等，这些都是需要读写分阁组件感知到底层数据库拓扑的变化。这里的难点在于几个方面：准确感知变化当出现网络等原因，底层发生变化，可能读写分理组件没有探亘到；或者探直本身就出现问题，没有发生变化而误认为发生变化。此时就会出现两张拓扑结构，一个实际结构，一是读写分离组件感知到的结构.这一问题，一方面可通过引入共识机制，增加多方判断解决；一方面也可通过与高可用组件互动减少误判.感知时效问题当发生拓扑变化后，从发生变化到祓读写分离组件感知是需要时间的，过短会导致数据库探查压力大；过长会影响整体恢复时间，这其中需要有个取舍.建议将这一能力开放给用户,由用户根据自身业务迸行

12、决策.同时也可与总可用组件互动，将拓扑变化信息尽快推送到读写分离组件，变被动探直为主动感知，提高时效性.人为干预能力除因故障等原因发生的拓扑变化外，有时还需人工干预读写分离.如发生机器维护、数据库升级等情况下，可提前通过人工手段，从拓扑结构中摘除相关节点，做到更加平顺。 个性化诉求除了上述要点外，还有些用户个性化的需求.如某个数据雇用户的访问只走主阵，某类应用的访问只走主库等，这类需求比较分散，比较好的处理方式是提供一定的脚本扩展能力，类似Iua扩展Nginx的方式.3 .读写分离：最佳实践D数据库优化手段对比读写分离技术，是一种有效的数据库访问优化手段，但不是唯一。随着业务增长，达到一定规模

13、后，提升数据库承载能力可以有多种方式，从大的分类来看可分为业务层优化、架构层优化、访问层优化与数据库优化几个方面。业务层-垂直拆分最为彻底的优化手段，在业务层就做了拆分，投入较高，但取得效果往往也比较可观。架构层-缓存/搜索通过引入缓存、搜索等技术，减轻对数据库压力，让数据库专注于有价值操作.这种方式需要一定改造工作量，取得收益取决于业务对数据的要求而定.访问层-读写分潮简单快速的优化方式，可快速提升性能，针对部分场景效果明显.访问层-分库分表分库分表方式，原理上是采取“大化小”的策略，但对于SQ1.兼容性有较高要求，会存在一定业务改造工作量.预期收益效果看规模和业务对数据要求而定.数据库-垂

14、直拆分对现有数据座根据业务进行拆分，难易程度及投入成本取决于之前架构设计，难点在于拆分后的数据交互,预期收益不很明确。数据库-垂直扩展对数据库升级是快速见效的措施，对应用几乎无影响，但需一定的成本投入及升级所需的中断服务的时间.取得收益存在上限瓶颈，预期中等。数据库-水平扩展对分库分表类似，但通常初始投入较大，对应用存在一定侵入性.层次手段说明底Ifl侵入性投入成本（含A/财）收4业务J2电为分雪拆分业务,IiW业务系统A9PWS引入口他技术,整轻DB负担中中/良中，访丽读药分离分离源与“作低低中分库分表水平拆分效三J中中/赛中/数WS里瓶分垂听分数庄，独立库低，中任/中低/中/毫SBFKIT

15、JB敛电S硬件低中/中中水平Irje水平拆分数穿，采用分布式在*/中/高中/离从上述对比可见，读写分离,可以说是对应用侵入最小，也最容易实现的优化手段.相对投入不到，就可取得一定效果.特别是对于大量读请求和少量写请求的业务场景，会有不错的效果.2）读写分厢适用场景读写分阁是一种简单有效的优化方式，但不是万能，具有若明显的适用场景特征.读多写少当单机数据阵不能支持业务的读写规模，就可以考虑读写分留.但需要考虑两者的比例，如果写操作比例大于读操作，那么大量写操作都在主库进行，读写分图达不到预期降低主阵压力的作用.一般来说，两者读写比越大，效果越好.当然还需考虑写规模不能也不能高于单机数据库支持规模。读有限扩展针对承载读的规模超大的情况，也需慎至.通过读写分离是可以实现一定程度读操作的横向扩展，但不是无限的，受限于数据库欠制的效率与成本，具存在扩展上限.对于大规模的可综合考虑缓存、数据拆分等多种手段.允许延迟针对主备方式难免存在延迟，因此对