百度指数 网站,哈尔滨市住房与城乡建设局网站,婚礼网站怎么做的,做商贸网站杨彪#xff0c;蚂蚁金服技术专家#xff0c;《分布式服务架构#xff1a;原理、设计与实战》和《可伸缩服务架构#xff1a;框架与中间件》作者。近10年互联网和游戏行业工作经验。本文节选自即将出版的《可伸缩服务架构#xff1a;框架与中间件》一书#xff0c;作者蚂蚁金服技术专家《分布式服务架构原理、设计与实战》和《可伸缩服务架构框架与中间件》作者。近10年互联网和游戏行业工作经验。本文节选自即将出版的《可伸缩服务架构框架与中间件》一书作者李艳鹏、杨彪、李海亮、贾博岩、刘淏。本文主要介绍使用分布式缓存的优秀实践和线上案例。这些案例是笔者在多家互联网公司里积累并形成的优秀实践能够帮助大家在生产实践中避免很多不必要的生产事故。一、缓存设计的核心要素我们在应用中决定使用缓存时通常需要进行详细的设计因为设计缓存架构看似简单实则不然里面蕴含了很多深奥的原理如果使用不当则会造成很多生产事故甚至是服务雪崩之类的严重问题。笔者在做设计评审的过程中总结了所有与缓存设计相关的设计点这里列出来供大家参考。1、容量规划缓存内容的大小缓存内容的数量淘汰策略缓存的数据结构每秒的读峰值每秒的写峰值2、性能优化线程模型预热方法缓存分片冷热数据的比例3、高可用复制模型失效转移持久策略缓存重建4、缓存监控缓存服务监控缓存容量监控缓存请求监控缓存响应时间监控5、注意事项是否有可能发生缓存穿透是否有大对象是否使用缓存实现分布式锁是否使用缓存支持的脚本Lua是否避免了Race Condition笔者在这里把这些设计点提供给读者请读者在做缓存设计时把每一项作为一个思考的起点思考我们在设计缓存时是否想到了这些点以避免在设计的过程中因忽略某一项而导致严重的线上事故发生。二、缓存设计的优秀实践笔者在做设计评审的过程中总结了一些开发人员在设计缓存系统时的优秀实践如下所述优秀实践1缓存系统主要消耗的是服务器的内存因此在使用缓存时必须先对应用需要缓存的数据大小进行评估包括缓存的数据结构、缓存大小、缓存数量、缓存的失效时间然后根据业务情况自行推算在未来一定时间内的容量的使用情况根据容量评估的结果来申请和分配缓存资源否则会造成资源浪费或者缓存空间不够。优秀实践2建议将使用缓存的业务进行分离核心业务和非核心业务使用不同的缓存实例从物理上进行隔离如果有条件则请对每个业务使用单独的实例或者集群以减小应用之间互相影响的可能性。笔者就经常听说有的公司应用了共享缓存造成缓存数据被覆盖以及缓存数据错乱的线上事故。优秀实践3根据缓存实例提供的内存大小推算应用需要使用的缓存实例数量一般在公司里会成立一个缓存管理的运维团队这个团队会将缓存资源虚拟成多个相同内存大小的缓存实例。例如一个实例有4GB内存在应用申请时可以按需申请足够的实例数量来使用对这样的应用需要进行分片详情请参考《可伸缩服务架构框架与中间件》中4.4.3的内容。这里需要注意如果我们使用了RDB备份机制每个实例使用4GB内存则我们的系统需要大于8GB内存因为RDB备份时使用了 copy-on-write 机制需要fork出一个子进程并且复制一份内存因此需要双份的内存存储大小。关于redis两种备份机制https://www.cnblogs.com/rollenholt/p/3874443.html优秀实践4缓存一般是用来加速数据库的读操作的一般先访问缓存后访问数据库所以缓存的超时时间的设置是很重要的。笔者曾经在一家互联网公司遇到过由于运维操作失误导致缓存超时设置得较长从而拖垮服务的线程池最终导致服务雪崩的情况。优秀实践5所有的缓存实例都需要添加监控这是非常重要的我们需要对慢查询、大对象、内存使用情况做可靠的监控。优秀实践6我们不推荐多个业务共享一个缓存实例但是由于成本控制的原因这种情况经常出现我们需要通过规范来限制各个应用使用的key有唯一的前缀并进行隔离设计避免产生缓存互相覆盖的问题。优秀实践7任何缓存的key都必须设定缓存失效时间且失效时间不能集中在某一点否则会导致缓存占满内存或者缓存雪崩。优秀实践8低频访问的数据不要放在缓存中如我们前面所说的我们使用缓存的主要目的是提高读取性能。曾经有个小伙伴设计了一套定时的批处理系统由于批处理系统需要对一个大的数据模型进行计算所以该小伙伴把这个数据模型保存在每个节点的本地缓存中并通过消息队列接收更新的消息来维护本地缓存中模型的实时性但是这个模型每个月只用了一次所以这样使用缓存是很浪费的。既然是批处理任务就需要把任务进行分割进行批量处理采用分而治之、逐步计算的方法得出最终的结果即可。优秀实践9缓存的数据不易过大尤其是Redis因为Redis使用的是单线程模型在单个缓存key的数据过大时会阻塞其他请求的处理。优秀实践10对于存储较多value的key尽量不要使用HGETALL等集合操作该操作会造成请求阻塞影响其他应用的访问。优秀实践11缓存一般用于在交易系统中加速查询的场景有大量的更新数据时尤其是批量处理时请使用批量模式但是这种场景较少。优秀实践12如果对性能的要求不是非常高则尽量使用分布式缓存而不要使用本地缓存因为本地缓存在服务的各个节点之间复制在某一时刻副本之间是不一致的如果这个缓存代表的是开关而且分布式系统中的请求有可能会重复就会导致重复的请求走到两个节点一个节点的开关是开一个节点的开关是关如果请求处理没有做到幂等就会造成处理重复在严重情况下会造成资金损失。优秀实践13在写缓存时一定要写入完全正确的数据如果缓存数据的一部分有效、一部分无效则宁可放弃缓存也不要把部分数据写入缓存否则会造成空指针、程序异常等。优秀实践14在通常情况下读的顺序是先缓存后数据库写的顺序是先数据库后缓存。优秀实践15在使用本地缓存如Ehcache时一定要严格控制缓存对象的个数及声明周期。由于JVM的特性过多的缓存对象会极大影响JVM的性能甚至导致内存溢出等。优秀实践16在使用缓存时一定要有降级处理尤其是对关键的业务环节缓存有问题或者失效时也要能回源到数据库进行处理。三、关于常见的缓存问题的线上案例笔者在多家互联网公司负责架构方案评审和线上事故复盘这里列举其中的一些典型案例供大家参考和借鉴。案例1现象某应用程序的数据库负载瞬时升高。原因在应用程序中对使用的大量缓存key设置了同一个固定的失效时间当缓存失效时会造成在一段时间内同时访问数据库造成数据库的压力较大。总结在使用缓存时需要进行缓存设计要充分考虑如何避免常见的缓存穿透、缓存雪崩、缓存并发等问题尤其是对于高并发的缓存使用需要对key的过期时间进行随机设置例如将过期时间设置为10秒random(2)也就是将过期时间随机设置成1012秒。案例2现象导致迁移前后两个系统的核心操作重复。原因在迁移的过程中重复的流量进入了不同的节点由于使用了本地缓存存储迁移开关而迁移开关在开关打开的瞬间导致各个节点的开关状态不一致有的是开、有的是关所以对于不同节点的流量的处理重复一个走了开关开的逻辑一个走了开关关的逻辑。总结避免使用本地缓存来存储迁移开关迁移开关应该在有状态的订单上标记。案例3现象某模块设计使用了缓存加速数据库的读操作的性能但发现数据库负载并没有明显下降。原因由于这个模块的使用方查询请求的数据在数据库中不存在是非法的数据所以导致缓存没有命中每次都穿透到数据库且量级较大。总结在使用缓存时需要进行缓存设计要充分考虑如何避免常见的缓存穿透、缓存雪崩、缓存并发等问题尤其是对高并发的缓存使用需要对无效的key进行缓存以抵挡恶意的或者无意的对无效缓存查询的攻击或影响。案例4现象监控系统报警Redis中单个哈希键占用的空间巨大。原因应用系统使用了哈希键哈希键本身有过期时间但是哈希键里面的每个键值对没有过期时间。总结在设计Redis的过程中如果有大量的键值对要保存则请使用字符串键的数据库类型并对每个键都设置过期时间请不要在哈希键内部存储一个没有边界的集合数据。实际上无论是对缓存、内存还是对数据库的设计如果使用任意一个集合的数据结构则都要考虑为它设置最大限制避免内存用光最常见的是集合溢出导致的内存溢出的问题。案例5现象某业务项目由于缓存宕机导致业务逻辑中断数据不一致。原因Redis进行主备切换导致瞬间内应用连接Redis异常应用并没有对缓存做降级处理。总结对于核心业务在使用缓存时一定要有降级方案。常见的降级方案是在数据库层次预留足够的容量在某一部分缓存出现问题时可以让应用暂时回源到数据库继续业务逻辑而不应该中断业务逻辑但是这需要严格的容量评估请参考《分布式服务架构原理设计与实战》第3章的内容。案例6现象某应用系统负载升高响应变慢发现应用进行频繁GC甚至出现OutOfMemroyError: GC overhead limt exceed的错误日志。原因因为这个项目是个历史项目使用了Hibernate ORM框架在Hibernate中开启了二级缓存使用了Ehcache但是在Ehcache中没有控制缓存对象的个数缓存对象增多导致内存紧张所以进行了频繁的GC操作。总结使用本地缓存如Ehcache、OSCache、应用内存时一定要严格控制缓存对象的个数及声明周期。案例7现象某个正常运行的应用突然报警线程数过高之后很快就出现了内存溢出。原因由于缓存连接数达到最大限制应用无法连接缓存并且超时时间设置得较大导致访问缓存的服务都在等待缓存操作返回由于缓存负载较高处理不完所有的请求但是这些服务都在等待缓存操作返回服务这时在等待并没有超时就不能降级并继续访问数据库。这在BIO模式下线程池就会撑满使用方的线程池也都撑满在NIO模式下一样会使服务的负载增加服务响应变慢甚至使服务被压垮。总结在使用远程缓存如Redis、Memcached时一定要对操作超时时间进行设置这是非常关键的一般我们设计缓存作为加速数据库读取的手段也会对缓存操作做降级处理因此推荐使用更短的缓存超时时间如果一定要给出一个数字则希望是100毫秒以内。案例8现象某项目使用缓存存储业务数据上线后出现错误问题开发人员束手无策。原因开发人员不知道如何发现、排查、定位和解决缓存问题。总结在设计缓存时要有降级方案在遇到问题时首先使用降级方法还要设计完善的监控和报警功能帮助开发人员快速发现缓存问题进而来定位和解决问题。案例9现象某项目在使用缓存后开发测试通过到生产环境后服务却出现了不可预知的问题。原因该应用的缓存key与其他应用缓存 key冲突导致互相覆盖出现逻辑错误。总结在使用缓存时一定要有隔离的设计可以通过不同的缓存实例来做物理隔离也可以通过各个应用的缓存key使用不同的前缀进行逻辑隔离。新书抢先看本文节选自即将出版的《可伸缩服务架构框架与中间件》一书此书现已开放预售可登录网址https://item.jd.com/12308233.html 抢先订购。更多新书精华内容也将由DBAplus社群陆续呈现。转载于:https://www.cnblogs.com/silyvin/p/9106612.html
