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

1 .读写分离：概述1）何为读号分离读写分离，从字面理解就是将对数据库的读操作与写操作分离的一种优化手段.其最早起源于互联网快速发展时期，面对海H用户访问问题，通过这一技术来解决数据库性能瓶颈问题。目前已经成为非甫常见的一种数据库访问优化技术.2）读写分离好处提高访问性能通过引入读写分离技术，将之前集中于单点的访问压力，分散到更多节点.即可利用更多的资源，支撑业务系统，可有效提升整体访问性能.提高稳定性通过将读取与写入操作的分窝,可有效规避由于异常操作所带来的风险,常见如一个大查询语句，因访问数据规模巨大占用大量CPU资源.通过承载端分离，可避免影响更为重要的写入操作。提高资源利用率为了更好地保护数据，数据库系统通常采用多副本技术冗余保护数据，但其备用副本如无法提供业务访问，将是一种资源浪费，而读写分商可有效利用只读副本，提升整体资源利用率。提高可用性通过引入更多节点来承载读写操作，结合负载均衡与高可用探苣技术，可避免单点故障引发可用性问题.提高访问效率通过利用不同节点分别承载读取与写入，还可缓解因为锁带来的争用问遗,提高单节点的访问效率.更大优化空间针对读取操作的特殊性，可通过分离后的独立资源采取特有的优化技术，进一步提升访问效率。2 .读写分离：技术实现1）常用方案目前业界流行的读写分离方案，通常都是基于上述主从模式的数据库架构，通过引入数据访问代理层，来实现访问动作的读写分离。引入数据访问代理的好处是源程序不需要做任何改动就可以实现读写分陶，坏处是由于多了一层中间件做中转代理，性能上会有所下降，数据访问代理也容易成为性能瓶颈，并且还存在一定维护成本.还有另一种方式，是将数据访问代理层前者到应用侧,通过SDK方式与应用集成在一起，可避免独立一层所带来的性能损耗和维护成本高的问返.但这种方式对开发语言有一定要求，存在适用性问题.访问性能中高维护成本中低易用性高中开发语言不限受限代理方式SDK方式2）技术要点读写分题功能的好与不好，主要是在易用性和灵活度问题.前者是关心如何让业务开发像操作单个主库一样,无需过多关注主从读写分离的细节，只耗要做好相应读写配冒后，就无需考虑写主读从的细节.后者是解决用户多变的业务场景和拓扑变化，并可实现自动适应。这其中是需要解决一系列技术问题,如下面这些常见的问题.判断读写攥作如何判断读写操作，是读写分离面临的首要问题.判断方式可大致分为自动和手动两种，前者是通过显式的方式由用户来指定；后者则是自动进行判断，用户无需关心.这两种判断方式往往是互补的，可配合来使用.下面是常见判断逻辅及处理：基于不同端口连接该实现方式就读写分离功能而言不是太好，因为此方式与应用自己实现没有明显差别，只是将直接连接不同数据库的逻相变成了连接中间件服务器的不同端口，并没有对应用系统开发带来实质性的简化工作。基于SQ1.匹配采用正则表达式匹配是比较容易实现的方案，可以无需应用的修改，只需要在中间件添加正则匹配的规则，即可将读、写分发的逻辑在中间件完成.读写分离的效果，取决于中间件的正则匹配规则的编写质用。基于Hint应用系统发送SQ1.时，可以添加Hint,显示的告诉中间件想要将该SQ1.发送到何处。中间件解析特定规则的Hint,即可实现对带有不同Hint的语句分发到不同的数据库节点.基于语法解析当中间件获取到应用发送的SQ1.字符串时，对其进行完整的语法解析，可以最大程度的获取SQ1.字符串中的信息，例如类型、操作对象等。基于语法的判断，就能够自动针对不同语句类型进行读写分发，可以最大限度的减少应用的适配工作.茶口连接SQ1.匹配Hint语法解析优点易实现应用无需改动应用控虫发应用无需改动M不荷化开发，与BS需配大量正则规应用®»需改造，有无法干预转发.用自壬实现无异则，漫作置杂，可改造成本活性稍差维IP性差使用语法解析是相对来说较为友好的方式，无需开发人员感知即可实现读写操作分离.但这其中存在难点，就是如何准确判断出只读操作存在一定困难，例如使用函数、存储过程、触发器或诸如"SE1.EeT“.FORUPDATE”类的操作。此时，是需要引入辅助机制进行判断,可采取配置名单方式来辅助分析或者通过Hint、API的方式强制指定走写库或读库.除此之外，还有些命令也需要规范是否可在备由执行，如COPY、SHOW,SET.BEGINEND等.如何处理事务事务类操作，往往藏味着数据变化,在读写分离中如何处理呢？通谓有两种思路，一种是简单粗基方式，将所有事务及关联操作全部发送到主机；一种是更为精确的处理，即分析事务内的语句序列，将事务中先写后读的对象进行关联，一起发送到主机，确保数据正确，而把和写操作无关的读操作，进行拆分，发送到备机执行.后一种处理方式能最大限度的利用读写分离，当然需要解决对象前后关系这一问颖.解决主笛延迟基于副本方式的延迟是常见的，也是读写分府在设计之初就需考虑的问题.其通常的处理思路可以有多种：强制读写走主席这类解决方案最简单粗品，也是实际工作中最常用的方案.通过对主备节点延迟情况的判断，来决定如何是走主库还是备库.通常可将延迟判断封装在中间层，前端应用可不感知，只需配置延迟阈值即可，当超过这一阈值就自动走主库.如下次访问时延迟低于阈值，可更新走备库.当然，这一方式无疑会加大对主库的压力.轮转和电试备库当在备库读取不到最新数据时，另一种思路多读取几次或者尝试读取其他备库.这里面的核心是对读取最新数据的判断，通常需要在应用开发时有所考虑才可.同时还需要制定退化方案，在何种情况下退化到读取主阵.结合缓存解决如延迟是常态，很难短期内解决，通过引入缓存可达到立竿见影的效果.其原理是在数据写入主库时，同步或异步写入缓存，应用读取时优先读取缓存，失效时才读取数据库.这种方案因引入缓存组件稍显且杂，需解决缓存与数据库同步更新及失效问期;同时对应用侧有一定影响,需感知到缓存.比较好的处理方式是都封装在中间层，通过它来统一处理访问逻辑。数据库优化展后一种就是尽见避免出现延迟，常见对数据库有些可优化的措施.例如尽量减少在主节点上执行大事务操作、减少主库索引进而减小写入开销、主备库采用不同存储引擎提升效率等等,当然这些方案只能起到一定作用，无法完全避免延迟问题.灵活负觑策Bg针对多个读库，读写分离组件还需提供灵活的负载均衡策略，常见的如随机、轮询、权生等等。这其中有几个特殊情况需要考虑：QoS不同读库的服务能力有所差异下，其能提供的服务保障不同，需在读写分题中提供例如权重的配首,进行干预。当然,更好的方式是提供服务质量评估机制，可根据各读库的服务能力进行分配.位在总知针对多AZ、多Region的情况，不同读库承载的角色不同，有的只作为备选主库不承担读、有的作为远程灾备等，因此在读写分离中希望能感知到这些信息，有所区别对待.往往可通过设置标签的方式解决，根据不同标签设在不同策略. 解决读一致性在读写分离中，当存在多个读库下，会因为延迟不同，出现读取不一致的情况.即路由到不同的读库，读取的数据鲜活度不同。这对于前端应用会造成一定困扰，解决的方法可采用会话粘性的策略,针对同一会话路由到同一读席,避免出现读不一致. 拓扑结构感知如果读写分离访问的数据集群拓扑发生变化，例如主备发生切换，写操作要到新的主座；亦或是增加了备旅数量，流量可以打到新备库等，这些都是需要读写分阁组件感知到底层数据库拓扑的变化。这里的难点在于几个方面：准确感知变化当出现网络等原因，底层发生变化，可能读写分理组件没有探亘到；或者探直本身就出现问题，没有发生变化而误认为发生变化。此时就会出现两张拓扑结构，一个实际结构，一是读写分离组件感知到的结构.这一问题，一方面可通过引入共识机制，增加多方判断解决；一方面也可通过与高可用组件互动减少误判.感知时效问题当发生拓扑变化后，从发生变化到祓读写分离组件感知是需要时间的，过短会导致数据库探查压力大；过长会影响整体恢复时间，这其中需要有个取舍.建议将这一能力开放给用户,由用户根据自身业务迸行决策.同时也可与总可用组件互动，将拓扑变化信息尽快推送到读写分离组件，变被动探直为主动感知，提高时效性.人为干预能力除因故障等原因发生的拓扑变化外，有时还需人工干预读写分离.如发生机器维护、数据库升级等情况下，可提前通过人工手段，从拓扑结构中摘除相关节点，做到更加平顺。 个性化诉求除了上述要点外，还有些用户个性化的需求.如某个数据雇用户的访问只走主阵，某类应用的访问只走主库等，这类需求比较分散，比较好的处理方式是提供一定的脚本扩展能力，类似Iua扩展Nginx的方式.3 .读写分离：最佳实践D数据库优化手段对比读写分离技术，是一种有效的数据库访问优化手段，但不是唯一。随着业务增长，达到一定规模后，提升数据库承载能力可以有多种方式，从大的分类来看可分为业务层优化、架构层优化、访问层优化与数据库优化几个方面。业务层-垂直拆分最为彻底的优化手段，在业务层就做了拆分，投入较高，但取得效果往往也比较可观。架构层-缓存/搜索通过引入缓存、搜索等技术，减轻对数据库压力，让数据库专注于有价值操作.这种方式需要一定改造工作量，取得收益取决于业务对数据的要求而定.访问层-读写分潮简单快速的优化方式，可快速提升性能，针对部分场景效果明显.访问层-分库分表分库分表方式，原理上是采取“大化小”的策略，但对于SQ1.兼容性有较高要求，会存在一定业务改造工作量.预期收益效果看规模和业务对数据要求而定.数据库-垂直拆分对现有数据座根据业务进行拆分，难易程度及投入成本取决于之前架构设计，难点在于拆分后的数据交互,预期收益不很明确。数据库-垂直扩展对数据库升级是快速见效的措施，对应用几乎无影响，但需一定的成本投入及升级所需的中断服务的时间.取得收益存在上限瓶颈，预期中等。数据库-水平扩展对分库分表类似，但通常初始投入较大，对应用存在一定侵入性.层次手段说明底Ifl侵入性投入成本（含A/财）收4业务J2电为分雪拆分业务,IiW业务系统«A9PWS引入口他技术,整轻DB负担中中/良中，访丽读药分离分离源与“作低低中分库分表水平拆分效三J中中/赛中/数WS里瓶分垂听分数庄，独立库低，中任/中低/中/毫SBFKITJB敛电S硬件低中/中中水平Irje水平拆分数穿，采用分布式在*/«中/高中/离从上述对比可见，读写分离,可以说是对应用侵入最小，也最容易实现的优化手段.相对投入不到，就可取得一定效果.特别是对于大量读请求和少量写请求的业务场景，会有不错的效果.2）读写分厢适用场景读写分阁是一种简单有效的优化方式，但不是万能，具有若明显的适用场景特征.读多写少当单机数据阵不能支持业务的读写规模，就可以考虑读写分留.但需要考虑两者的比例，如果写操作比例大于读操作，那么大量写操作都在主库进行，读写分图达不到预期降低主阵压力的作用.一般来说，两者读写比越大，效果越好.当然还需考虑写规模不能也不能高于单机数据库支持规模。读有限扩展针对承载读的规模超大的情况，也需慎至.通过读写分离是可以实现一定程度读操作的横向扩展，但不是无限的，受限于数据库欠制的效率与成本，具存在扩展上限.对于大规模的可综合考虑缓存、数据拆分等多种手段.允许延迟针对主备方式难免存在延迟，因此对于延迟很敏感的操作不适于此方案。非宜杂查询采用读写分离能在一定程度上解决查询效率问题，但针对聂杂萱询试图通过这一方式去解决不是一个好的思路.这类诉求建议通过搜索引擎、O1.AP等技术去解决.4 .读写分离：典型产品架构举例业内有很多读写分离方案，一类是采用中间件思路开发，以开源产品为主；一类是数据库产品，内古读写分离功能.下面简单介绍下几种产品路线：1) MySQ1.-ProxyMySQ1.-Proxy是MySQ1.官方提供的MySQ1.中间件服务.MySQ1.-Proxy实际上是在客户端谙求与MySQ1.Server之间建立了一个连接池.所有客户端诘求都是发向MySQ1.-ProXy,然后经由MySQ1.-ProXy进行相应的分析，判断出是读操作还是写掇作，分发至对应的MySQ1.Server上.对于多节点Slave集群，也可以起做到负载均衡的效果.#7mysql-proxy-daemon-Iog-IeveI=Ciebug-user=mysql-keepalive-log-file=varlogmysql-proxy.log-plugins="proxy'-proxy-backend-addresses="192.168.1.5:3306'-proxy-read-only-backend-addresses=192.168.1.6:3306*-proxy-lua-script=rootsoftmysql-proxyrw-splittir>g.lua*-plugis=admin-admin-useram="admi-adminpassword=*admi-admi-lua-script,rootsoftmysql-proxyhbmysq-proxyluaadmin.lua其中proxy-backend-addresses是master服务器，proxy-read-only-backend-addresses是slave服务器.2) ApacheShardingSphereApacheShardingSphere是一款开源的数据库中间件产品，并在APaChe基金会毕业，可以说是非常成熟的开源项目.其产昆内皆了丰富的功能，包括读写分离能力，具体包括：支持动态、静态读写分离能力，支持自动拓扑膝知与人工设定.支持多种数据库（如MySQ1.、PG、OpenGauss等）及多种架构（如MySQ1.主从、MGR等）支持多端接入（DriVer、ProXy）,可满足低时延场景支持语法解析自动判断或Hint方式手工指定支持包括熔断等能力的人工干预手段，可适应多种场景支持类SQ1.的管理配正方式，支持热加载配置支持丰亩的负载均衡算法，如下图说明以法名祢1ROUND.ROBIN基于轮询的读库负野为所算法2RANDOM幕于糖机的武为负我均衡算法3WEIGHT“于权期读库负蚊均衢算法4TRANSACTION-RANDOM无论是否在事务中，读Sr求采用Ii机策略路由资务个读库5TRANSACTION.ROUND.ROBIN无论JS否在事务中，读满来采用轮潮例8路由到多个谈库6Transaction.WEIGHT无论是否在期若中，谈酒卿用权三策略珞由鳄多个读库7FlXEDeREP1.lCAeRANDOM显式开启事务，读请求采用随机集略珞由到一个固定读®不开事务，每次送M使用RS定货法珞由到不同的读库8FIXED.REP1.ICA.ROUND.ROBINSS式开启事务.读请求采用抡词第略SS由到一个固定读«不开事务.每次读流量使用指定算法路由到不同的读S9FIXED.REP1.ICA.WEIGHT曼式开启事务，读调荻采用权员第略18由到多个读库；不开事务,每次试流使用瘠定复法18由到不同的BE库10FIXED.PRIMAfiY读请求全部路由到主库3) MyCATMyCAT是一款开源的数据库中间件产品。读写分离功能通过配置文件完成，如下balance,读写分离策略O,不开启读写分离机制，所有读操作发到当前可用WriteHost上1 ,全部readHost与standbyWriteHost参与select语句负载均衡2 ,所有读操作都随机在WriteHost、readhost上分发3 ,所有读请求随机分发到readhostWriteType,写模式0,所有的操作发送到配置的第一个writehost1,随机发送到配置的所有writehost2,不执行写操作SwitchType,切换模式-1,表示不自动切换1,默认值,表示自动切换2 ,基于MySQ1.主从同步的状态决定是否切换3 ,基于MySQ1.galarycluster的切换机制4 ）RDS数据库代理（以RDSPG为例）数据库代理是数据库RDS提供的一款安全、稳定、高性能，对应用完全透明的数据由中间层服务.数据库代理是位于数据南服务端和应用服务端之间的网络代理服务，代理服务端代替应用服务端数据库发送和接受所有数据库请求，进而可以在代理服务层上实现比如读写分离、连接池、端对端加密、防闪断等附加功能.通过数据库代理用户只需要通过一个链接地址即可实现读写分离架构，读写属性和只读属性的多样化选择满足了不同业务场景.回E回一口二口二丁2-is数据库代理支持了PostgreSQ1.的协议，并且具备对用户的请求连接认证权限的能力.代理中的路由策略是核心：可以通过hint中指定固定的实例节点来转发流量；也能够将事务内写操作之前的读请求转发到只读实例，降低主实例负载；路由策略还可以根据用户自定义的只读模式或读写模式对请求进行不同的分发执行.健原巡检模块周期性感知读写分离架构的拓扑变化情况，在实例节点不健康或者超过延迟阈值，会自动把读请求路由到其他的只读实例上.5 )OceanBaseOceanBase数据库天然支持读写分留的功能，即通过OBProXy代理服务和修改OBSerVer的配置即可实现业务的读写分离策略.OCeanBaSe数据库在读取数据时，提供了两种一致性级别：强一致性和弱一致性.强一致性是指请求路由给主副本读取最新数据；弱一致性是指请求优先路由给备副本，不要求读取最新数据.通过应用侧为执行的SQ1.添加SQ1.Hint来显性开启弱一致性读就可以实现基于注释的读写分寓功能，同时也衍生出如下三种常用的读写分离策略：仅凭it«2M通过怫MoeeelyffW由第RlOKJHt,并符MIXzonWSht流即fOBProwyMjWit家优先6W阳fo*A*芯.T«&lRZorwCS4<w«MIM1.DC只W本为用Ija，标*.WOBPioxyS马充金IM存在SNTRd99MJprcxxy.MJc.mm»dc.在曲努区£M说丁.理好澹虎5附设OBProiy.处IDC配仅5府只图11*.1.DC金g本迁地金切IeNW8.(Wi尊只有挚懒血，的if>5K全aZM.11WMR仙色存在MwMrMmdc三,再性.O6P*oxy的th8yj<fc.sMlMiXIDC首卷.a*VS.中建武司谀OePraXy.Ail1.DC配仅承鼻本.艾国型5发品全分，6 )KunIunBaseKUnIUnBaSe是一个开源、高性能的分布式关系数据座，支持混合负载、PB级数据11管理并提供亳秒延迟的新一代数据库解决方案.nauaKunlunBase的读写分离在计肾层的远程查询优化器内实现的，当用户的SQ1.同时满足如下条件：当前SQI类型为SeIeCt;SQ1.中不包含用户自定义函数，除非当前事务为只读事务；如果不在事务中(autocommit=on),则允许读写分离;如果语句在显式事务中，则要满足：-如果在只读事务中，则允许读写分离；-如果在读写事务中，则该事务未更新过数据.远程宜询优化器就会将相应的SQ1.执行计划下发到从备机的节点上执行.KunIunServer会根据以下规则选择发送SeIeCt语句到目标存储集群的哪个备机节点：根据节点权重值选择(ro.weight)根据网络延迟(Ping)根据主从副本的数据一致性延迟(latency)1-sch>.xl2<?»1vtr$ion.-1.0"?>3<!DOCTYPE*ycat:sch«MSYSTEMFChma.dt<>4<*yctztcR4XBlnsJyct三-httporg.opencloub'>5<schiMnm*t5tcheckSQ1.$ch«<M«Mfelse111'sqlMax1.imitwl0dataNoda,dnl*>6<>chemna三"testlcheckSQtschea三,<alse*sqlMaxliit"ieedataHode"dn2>74dtM8nit三-dnl-d<t«Host«MIocalhostl*databasoMt«stM>8<dataNodtnft"dn2"dtHostwIocelhostl"databe$e«Mt«stlM>9CdatiMostna-loclho*rX-xConieee-minCon«*ie"blncwl16writeType-0"dbType>Ni*y$ql"dbDrivr三"ntivswitchType"lslveTrshold"1W>11<h«artb«at>slctusr()<bartbat>12<WriteHosthost"hostMlurl"localhost:33e6"usrroofpssworda*>13<writHothost«HhottSlwurl三,192.168.1.1:3306-usr三"root*password.->14<dataHost>15</«yc«t:»cheea>