比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
国内外三个领域巨头告诉你Redis怎么用
关键字：Redis
　　随着数据体积的激增，+memcache已经满足不了大型类应用的需求，许多机构也纷纷选择Redis作为其架构上的补充。这里我们将为大家分享社交巨头、传媒巨头Viacom及图片分享领域Pinterest带来的Redis实践。
　　新浪：史上最大的Redis集群
　　Tape is Dead，Disk is Tape，Flash is Disk，RAM Locality is King. ― Jim Gray
　　Redis不是比较成熟的memcache或者Mysql的替代品，是对于大型互联网类应用在架构上很好的补充。现在有越来越多的应用也在纷纷基于Redis做架构的改造。首先简单公布一下Redis平台实际情况：
　　2200+亿 commands/day 5000亿Read/day 500亿Write/day
　　18TB+ Memory
　　500+ Servers in 6 IDC 2000+instances
　　应该是国内外比较大的Redis使用平台，今天主要从应用角度谈谈Redis服务平台。
　　Redis使用场景
　　1.Counting(计数)
　　计数的应用在另外一篇文章里较详细的描述，计数场景的优化 http://www.xdata.me/?p=262这里就不多加描述了。
　　可以预见的是，有很多同学认为把计数全部存在内存中成本非常高，我在这里用个图表来表达下我的观点：
　　很多情况大家都会设想纯使用内存的会很有很高成本，但实际情况往往会有一些不一样：
　　COST，对于有一定吞吐需求的应用来说，肯定会单独申请DB、Cache资源，很多担心DB写入性能的同学还会主动将DB更新记入异步队列，而这三块的资源的利用率一般都不会太高。资源算下来，你惊异的发现：反而纯内存的方案会更精简!
　　原则，这对于开发是非常友好的，我只需要建立一套连接池，不用担心数据一致性的维护，不用维护异步队列。
　　Cache穿透风险，如果后端使用DB，肯定不会提供很高的吞吐能力，cache宕机如果没有妥善处理，那就悲剧了。
　　大多数的起始需求，容量较小。
　　2.Reverse cache(反向cache)
　　面对微博常常出现的热点，如最近出现了较为火爆的短链，短时间有数以万计的人点击、跳转，而这里会常常涌现一些需求，比如我们向快速在跳转时判定用户等级，是否有一些账号绑定，性别爱好什么的，已给其展示不同的内容或者信息。
　　普通采用memcache+Mysql的解决方案，当调用id合法的情况下，可支撑较大的吞吐。但当调用id不可控，有较多垃圾用户调用时，由于memcache未有命中，会大量的穿透至Mysql，瞬间造成连接数疯长，整体吞吐量降低，响应时间变慢。
　　这里我们可以用redis记录全量的用户判定信息，如string key:uid int:type，做一次反向的cache，当用户在redis快速获取自己等级等信息后，再去Mc+Mysql层去获取全量信息。如图：
　　当然这也不是最优化的场景，如用Redis做bloomfilter，可能更加省用内存。
　　3.Top 10 list
　　总会让你展示最近、最热、点击率最高、活跃度最高等等条件的top。很多更新较频繁的列表如果使用MC+MySQL维护的话缓存失效的可能性会比较大，鉴于占用内存较小的情况，使用Redis做存储也是相当不错的。
　　4.Last Index
　　用户最近访问记录也是redis list的很好应用场景，lpush lpop自动过期老的登陆记录，对于开发来说还是非常友好的。
　　5.Relation List/Message Queue
　　这里把两个功能放在最后，因为这两个功能在现实问题当中遇到了一些困难，但在一定阶段也确实解决了我们很多的问题，故在这里只做说明。
　　Message Queue就是通过list的lpop及lpush接口进行队列的写入和消费，由于本身性能较好也能解决大部分问题。
　　6.Fast transaction with Lua
　　Redis 的Lua的功能扩展实际给Redis带来了更多的应用场景，你可以编写若干command组合作为一个小型的非阻塞事务或者更新逻辑，如：在收到message推送时，同时1.给自己的增加一个未读的 2.给自己的私信增加一个未读消息 3.最后给发送人回执一个完成推送消息，这一层逻辑完全可以在Redis Server端实现。
　　但是，需要注意的是Redis会将lua script的全部内容记录在aof和传slave，这也将是对，网卡一个不小的开销。
　　7.Instead of Memcache
　　很多测试和应用均已证明，
　　在性能方面Redis并没有落后memcache多少，而单线程的模型给Redis反而带来了很强的扩展性。
　　在很多场景下，Redis对同一份数据的内存开销是小于memcache的slab分配的。
　　Redis提供的数据，其实是对cache的一个强有力功能扩展。
　　Redis使用的重要点
　　1.rdb/aof Backup!
　　我们线上的Redis 95%以上是承担后端存储功能的，我们不仅用作cache，而更为一种k-v存储，他完全替代了后端的存储服务(MySQL)，故其数据是非常重要的，如 果出现数据污染和丢失，误操作等情况，将是难以恢复的。所以备份是非常必要的!为此，我们有共享的hdfs资源作为我们的备份池，希望能随时可以还原业务 所需数据。
　　2.Small item & Small instance!
　　由于Redis单线程(严格意义上不是单线程，但认为对request的处理是单线程的)的模型，大的数据结构list,sorted set,hash set的批量处理就意味着其他请求的等待，故使用Redis的复杂数据结构一定要控制其单key-struct的大小。
　　另外，Redis单实例的内存容量也应该有严格的限制。单实例内存容量较大后，直接带来的问题就是故障恢复或者Rebuild从库的时候时间较长，而更糟糕的是，Redis rewrite aof和save rdb时，将会带来非常大且长的系统压力，并占用额外内存，很可能导致系统内存不足等严重影响性能的线上故障。我们线上96G/128G内存服务器不建议单实例容量大于20/30G。
　　3.Been Available!
　　业界资料和使用比较多的是Redis sentinel(哨兵)
　　http://www.huangz.me/en/latest/storage/redis_code_analysis/sentinel.html
　　/wellflat/items/8935016fdee25d4866d9
　　2000行C实现了服务器状态检测，自动故障转移等功能。
　　但由于自身实际架构往往会复杂，或者考虑的角度比较多，为此 @许琦eryk和我一同做了hypnos项目。
　　hypnos是神话中的睡神，字面意思也是希望我们工程师无需在休息时间处理任何故障。:-)
　　其工作原理示意如下：
　　Talk is cheap, show me your code! 稍后将单独写篇博客细致讲下Hypnos的实现。
　　4.In Memory or not?
　　发现一种情况，开发在沟通后端资源设计的时候，常常因为习惯使用和错误了解产品定位等原因，而忽视了对真实使用用户的评估。也许这是一份历史数据，只有最近一天的数据才有人进行访问，而把历史数据的容量和最近一天请求量都抛给内存类的存储现实是非常不合理的。
　　所以当你在究竟使用什么样的数据结构存储的时候，请务必先进行成本衡量，有多少数据是需要存储在内存中的？有多少数据是对用户真正有意义的。因为这其实对后端资源的设计是至关重要的，1G的数据容量和1T的数据容量对于设计思路是完全不一样的
　　Plans in future?
　　1.slave sync改造
　　全部改造线上master-slave数据同步机制，这一点我们借鉴了MySQL Replication的思路，使用rdb+aof+pos作为数据同步的依据，这里简要说明为什么官方提供的psync没有很好的满足我们的需求：
　　假设A有两个从库B及C，及 A `― B&C，这时我们发现master A服务器有宕机隐患需要重启或者A节点直接宕机，需要切换B为新的主库，如果A、B、C不共享rdb及aof信息，C在作为B的从库时，仍会清除自身数 据，因为C节点只记录了和A节点的同步状况。
　　故我们需要有一种将A`CB&C 结构切换切换为A`CB`CC结构的同步机制，psync虽然支持断点续传，但仍无法支持master故障的平滑切换。
　　实际上我们已经在我们定制的Redis计数服务上使用了如上功能的同步，效果非常好，解决了运维负担，但仍需向所有Redis服务推广，如果可能我们也会向官方Redis提出相关sync slave的改进。
　　2.更适合redis的name-system Or proxy
　　细心的同学发现我们除了使用DNS作为命名系统，也在zookeeper中有一份记录，为什么不让用户直接访问一个系统，zk或者DNS选择其一呢？
　　其实还是很简单，命名系统是个非常重要的组件，而dns是一套比较完善的命名系统，我们为此做了很多改进和试错，zk的实现还是相对复杂，我们还没有较强的把控粒度。我们也在思考用什么做命名系统更符合我们需求。
　　3.后端数据存储
　　大内存的使用肯定是一个重要的成本优化方向，flash盘及分布式的存储也在我们未来计划之中。
[ 责任编辑：杨瑷嘉 ]
去年，手机江湖里的竞争格局还是…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注Chinabyte用户：****
用户：**shineice@ye**
用户：**shineice@ye**
用户：****
用户：****
用户：****
用户：****
用户：****
用户：**shineice@ye**
用户：****
用户：****
用户：****
用户：****
用户：**8435048@qq.**
用户：****
用户：****
用户：****
用户：****
用户：**0934644@qq.**
用户：****
公告：因课程即将全面升级，2017年度所有课程进行统一调价！&&&&&&&&&&&&&&公告：因课程即将全面升级，2017年度所有课程进行统一调价&&&&&&&&&&&&&&&
分享：9999+
课程顾问贴心解答
为你推荐精品课程，无论就业还是升职加薪，毫无压力。
名企定制紧随大流
量身打造紧贴企业需求的实用性课程。
系统教学把控效果
集学、测、练为一体的学习系统为你科学的安排学习进度，提高效率。
一线大师1对1指导
课程研发团队内一线资深讲师一对一指导，手把手教学，直到学会。
点播答疑完美结合
每周2-3次直播解答，保证学员日常学习问题能得到解决。
量身定制学习计划
告别杂乱的学习方式，我们会根据你的情况定制学习计划。
Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类keyvalue存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Python，Ruby，Erlang，PHP客户端，使用很方便。
最佳应用场景:适用于数据变化快且数据库大小可遇见（适合内存容量）的应用程序。
例如:股票价格、数据分析、实时数据搜集、实时通讯。现阶段流行的新浪微博就是用的Redis
性能测试结果:
SET操作每秒钟 110000 次，GET操作每秒钟 81000 次，
服务器配置如下：
Linux 2.6, Xeon XGhz.
stackoverflow 网站使用 Redis 做为缓存服务器。
1.redis介绍和基本使用，安装redis，安装php-redis
2.redis数据类型string，Web Session缓存
3.使用redis进行数据库缓存，redis数据类型list
4.redis的数据持久机制及订阅/发布模型
5.redis数据类型set/sorted set，使用redis实现auto complete
6.基于访问频率的auto complete，redis的内存分配方法
7.redis数据类型hash，redis数据类型的内存模型（1）
8.redis数据类型的内存模型（2），与key相关的操作方法
9.如何分布式的使用redis，transaction和server相关的操作，redis接口协议
10.使用redis实现一个简单的微博系统
您暂未登录不能收藏！请登录后在进行课程的收藏！令人更想不到的是，车上居然还坐着一车“妖魔鬼怪”。
北京电影学院2017年度招考开始，考场外帅哥美女如云。
声明：本文由入驻搜狐公众平台的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
　　作者：王晓波，同程旅游首席架构师。专注于高并发互联网架构设计、分布式电子商务交易平台设计、大数据分析平台设计、高可用性系统设计，基础云相关技术研究，对 Docker 等容器有深入的实践。另对系统运维和信息安全领域也大量的技术实践。曾设计过多个并发百万以上、每分钟 20 万以上订单量的电商交易平台，熟悉 B2C、B2B、B2B2C、O2O 等多种电商形态系统的技术设计。 熟悉电子商务平台技术发展特点，拥有十多年丰富的技术架构、技术咨询经验，深刻理解电商系统对技术选择的重要性。
　　缓存大家比较熟悉，在各种场景下也用的很多，在同程旅游也一样，缓存是一个无处不在的精灵，也是抗并发压力的核心系统之一。今天我们来讲一下同程旅游在缓存方面的一些经验，包括整个缓存架构如何设计。先来看一下缓存我们走过了哪些历程。最早我们在应用中使用内存对象来存放变化比较小数据，慢慢的发现在应用本地的内存量是不足以这样折腾的是精贵的，所以开始使用从 memcache 来将缓存从应用中分离出来。之后缓存的场景变的更多了，memcache的一些不足之处开始显现，如支持的数据结构有单一等。于是又开始使用Redis，对于Redis的使用也从单机开始转向分片／集群的方式。Redis虽然是一个非常优秀的缓存中间件系统但当应用的使用量越来越多时发现新的问题也来了，首先是对于在应用代码在一起的Redis客户端不是太满意了，于是我们重写了客户端。接着在数千个Redis实例（目前我们线上有4千多个部署实例）在线上工作起来如何底成本的高效的运维起是一个大挑战。于是我们做了针对他的智能化运维平台。但是这些多不是重大的难题，最大难题是因为Redis太好用了于致于在应用项目中大量的使用，但是往往这些是没有好好的思考和设计过的，这样情况使的缓存的使用是混乱的不合理的，也使的原本健壮的缓存变的脆弱的病秧子。所以我们开始做了开发 Redis 调度治理系统来治理缓存。到现在我们开始更加关注整个缓存平台的高效和低成本所以在平台的Redis 部署全面 Docker 化，并开始让比内存廉价的ssd硬盘在缓存中使用起来。
　　现在让我们来看一看这个名叫“凤凰”的缓存平台是怎么从火中重生的。
　　一、Redis 遍地开花的现状及问题
　　1. Redis 集群的管理
　　所有互联网的应用里面，可能访问最多的就是 cache。一开始时候一些团队认为 cache 就像西游记里仙丹一样，当一个系统访问过大扛不住时，用一下 Redis，系统压力就解决了。在这种背景下，我们的系统里面 Redis 不断增多，逐渐增加到几百台服务器，每台上面还有多个实例，因此当存在几千个 Redis 实例后，使用者也很难说清楚哪个 Redis在哪个业务的什么场景下影响什么功能。
　　2. 故障
　　这种背景下会存在什么样痛苦的场景？正常情况下 cache 是为了增加系统的性能，是画龙点睛的一笔，但是当时我们 cache 会是什么样？它挂了就可能让我们整个系统崩溃。比如说 系统压力才不到高峰时的 10%，也许就由于缓存问题系统就挂了，又比如系统的访问量不大，但某个缓存被调用到爆了，因为缓存的乱用后调用量被放大了。
　　3. 高可用与主从同步问题
　　因为 cache 有单点，我们一开始想放两份不就好了吗，所以就做了主从。这时候坑又来了，为什么呢？比如有些 Redis 实例中的某个键值非常大（在乱的场景下我见到过有人一个键值放到10G的）。在当偶尔网络质量不太好时候，就会带来主从同步基本就别想了，更坑的是当两边主和从都死或者出问题的时，重启的时间非常长。
　　4. 监控
　　为了高可用，我们需要全面的监控。当时我们做了哪些监控呢？其实是能做的监控我们多做了，但问题没有解决，细想来问题到底在哪？
　　下面是一个接近真实场景运维与开发的对话场景。
开发：Redis 为啥不能访问了？
运维：刚刚服务器内存坏了，服务器自动重启了
开发：为什么 Redis 延迟这么大？
运维：不要在 Zset 里放几万条数据，插入排序会死人啊
开发：写进去的 key 为什么不见了？
运维：Redis 超过最大大小了啊，不常用 key 都丢了啊
开发：刚刚为啥读取全失败了
运维：网络临时中断了一下，从机全同步了，在全同步完成之前，从机的读取全部失败
开发：我需要 800G 的 Redis，什么时候能准备好？
运维：线上的服务器最大就 256G，不支持这么大
开发：Redis 慢得像驴，服务器有问题了？
运维：千万级的 KEY，用 keys*，慢是一定了。
　　看到这样的一个场景很吃惊，我们怎么在这样用缓存，因此我们一个架构师最后做了以下总结
　　“从来没想过，一个小小的 Redis 还有这么多新奇的功能。就像在手上有锤子的时候，看什么都是钉子。渐渐的，开发规范倒是淡忘了，新奇的功能却接连不断的出现了，基于 Redis 的分布式锁、日志系统、消息队列、数据清洗等，各种各样的功能不断上线，从而引发各种各样的问题。运维天天疲于奔命，到处处理着 Redis 堵塞、网卡打爆、连接数爆表……”
　　总结了一下，我们之前的缓存存在哪些问题？
使用的者的乱用、烂用、懒用。
运维一个几百台毫无规则的服务器
运维不懂开发，开发不懂运维
缓存在无设计无控制中被使用
开发人员能力各不相同
使用太多的服务器
懒人心理（应对变化不够快）
二、我们需要一个什么样的完美缓存系统？
　　我相信上面这些情况在很多大量使用 Redis 的团队中都存在，如果发展到这样一个阶段后，我们到底需要一个什么样的缓存？
　　我们给自己提出几个要点：
服务规模：支持大量的缓存访问，应用对缓存大少需求就像贪吃蛇一般
集群可管理性：一堆孤岛般的单机服务器缓存服务运维是个迷宫
冷热区分：现在缓存中的数据许多并不是永远的热数据
访问的规范及可控：还有许多的开发人员对缓存技术了解有限，胡乱用的情况很多
在线扩缩容：起初估算的不足到用时发现瓶颈了
　　这个情况下，我们考虑这样的方案是不是最好。本来我们是想直接使用某个开源方案就解决了，但是我们发现每个开源方案针对性的解决 Redis 上述痛点的某一些问题，每一个方案在评估阶段跟我们需求都没有 100% 匹配。每个开源方案本身都很优秀，也许只是说我们的场景的特殊性，没有任何否定的意思。
　　下面我们当时评估的几个开源方案，看一下为什么当时没有引入。
CacheCloud：跟我们需要的很像，它也做了很多的东西，但是它对我们不满足是部署方案不够灵活，对运维的策略少了点。
Codis：这个其实很好，当年我们已经搭好了准备去用了，后来又下了，因为之前有一个业务需要 800G 内存，后来我们发现这个大集群有一个问题，因为用得不是很规范，如果在这种情况下给他一个更大的集群，那我们可能死的机率更大，所以我们也放弃了。另外像这个800G 也很浪费，并不完全都是热数据，我们想把它存到硬盘上一部分，很多业务使用方的心理是觉得在磁盘上可能会有性能问题，还是放在 Redis 放心一点，其实这种情况基本不会出现，因此我们需要一定的冷热区分支持。
**Pika：**Pika 可以解决上面的大量数据保存在磁盘的问题，但是它的部署方案少了点，而且 Pika 的设计说明上也表示主要针对大的数据存储。
Twemproxy：最后我们想既然直接方案不能解决，那可以考虑代理治理的方式，但是问题是它只是个代理，Redis 被滥用的问题还是没有真正的治理好，所以后面我们准备自己做一个。
三、全新设计的缓存系统――凤凰
　　我们新系统起了一个比较高大上的名字，叫凤凰，愿景是凤凰涅磐，从此缓存不会再死掉了。那么，凤凰是怎么设计的？（如：图1）
　　主要是做好了下面的几件事：
在应用中能根据场景拆分（应用透明）
能从客户端调用开始全面监控
能防止缓存的崩塌
动态扩容缩容
　　图1: 凤凰缓存平台的基础设计
　　1. 自定义客户端方式与场景配置能力
　　在支持 Redis 本身的特性的基础上，我们需要通过自定义的客户端来实现一些额外的功能。
　　支持场景配置，我们考虑根据场景来管控它的场景，客户端每次用 Redis 的时候，必须把场景上报给我，你是在哪里，用这件事儿是干什么的，虽然这个对于开发人员来说是比较累的，他往往嵌在它的任务逻辑里面直接跟进去。曾江场景配置之后，在缓存服务的中心节点，就可以把它分开，同一个应用里面两个比较重要的场景就会不用同一个 Redis，避免挂的时候两个一起挂。
　　同时也需要一个调度系统，分开之后，不同的 Redis 集群所属的服务器也需要分开。分开以后我的数据怎么复制，出问题的时候我们怎么把它迁移？因此也需要一个复制和迁移的平台去做。
　　另外这么一套复杂的东西出来之后，需要一个监控系统；客户端里也可以增加本地 cache 的支持。在业务上也可能需要对敏感的东西进行过滤。在底层，可以自动实现对访问数据源的切换，对应用是透明的，应用不需要关心真正的数据源是什么，这就是我们自己做的客户端。（如：图2）
　　图2: 凤凰缓存平台客户端的结构图
　　2. 代理层方式
　　客户端做了之后还发生一个问题，很多情况下很难升级客户端。再好的程序员写出来的东西还是有 bug，如果 Redis 组件客户端发现了一个 bug 需要升级，但我们线上有几千个应用分布在多个业务开发团队，这样导致很难驱动这么多开发团队去升级。另外一个我们独有的困难，就是我们还有一些很老的应用开发时用的 .net，这些虽然现在基本是边缘应用了但还在线上，当然我们也把客户端实现了 .net 版本，但是由于各种原因，要推动这么多历史业务进行改造切换非常麻烦，甚至有些特别老的业务最后没法升级。另外我们也推进其（如：go等）其它语言的应用想让技术的生态做的更丰富。这样一来我们做维护更多语言的客户端了，这样的方式明显不合适。
　　因此我们考虑了 proxy 方案，这些业务模块不需要修改代码，我们的想法就是让每一个项目的每一个开发者自己开发的代码是干净的，不要在他的代码里面嵌任何的东西，业务访问的就是一个 Redis。那么我们就做了，首先它是 Redis 的协议，接下来刚才我们在客户端里面支持的各种场景配置录在 proxy 里面，实现访问通道控制。然后再把 Redis 本身沉在我们 proxy 之后，让它仅仅变成一个储存的节点，proxy 再做一些自己的事情，比如本地缓存及路由。冷热区分方面，在一些压力不大的情况下，调用方看到的还是个 Redis ，但是其实可能数据是存在 RocksDB 里面了。（如：图3）
　　图3: 凤凰缓存平台的代理设计
　　3. 缓存服务的架构设计
多个小集群 + 单节点，我们要小集群的部署和快速的部署，到当时一个集群有问题的时候，快速移到另一个集群。
以场景划分集群
实时平衡调度数据
动态扩容缩容
　　图4:以Docker的基础的凤凰缓存平台架构设计
　　4. 可扩容能力
流量的快速增加必然带扩容的需求与压力
容量与流量的双扩容
如何做到平滑的扩容？容量动态的数据迁移(集群内部平衡，新节点增加)；流量超出时的根据再平衡集群。
　　图5: 凤凰缓存平台的平滑的扩容过程
　　5. 多协议支持
　　还有一块老项目是最大的麻烦，同程有很多之前是用 memcache 的应用，后来是转到 Redis 去的，但是转出一个问题来了，有不少业务由于本身事情较多，没有时间转换成 Redis，这些钉子户怎么办？同时维护这两个平台是非常麻烦的，刚才 proxy 就派到用场了。因为 memcache 本身它的数据支持类型是比较少的，因此转换比较简单，如果是一个更复杂的类型，那可能就转不过来了。所以我们 proxy 就把这些钉子户给拆掉了，他觉得自己还是在用 memcache，其实已经被转成了 Redis。
　　图6: 凤凰缓存平台的多协议支持设计）
　　6. 管理与可监控能力
　　最后一块，我们这样一个平台怎么去监控它，和怎么去运维它？
　　在这块我们更多的是在做一个智能化的运维平台。主要的几点方向：
整体的管制平台，
运维操作平台，让它可以去操作，动态的在页面上操作做一件事情，
整体监控平台。我们从客户端开始，到服务器的数据，全部把它监控起来。
自扩容自收缩。动态的自扩容，自收缩。
　　7. 一些业务应用场景
　　也是用了一些场景，比如说同程前两年冲的比较狠的就是一元门票，大家肯定说抢购，这个最大的压力是什么，早上的九点半，这是我们系统最大的压力，为什么呢，一块钱的门票的从你买完票到景区里面去，这件事情是在九点半集中爆发的，你要说这个是系统挂了入不了园了，那十几万人不把这个景区打砸了才怪。那个时候系统绝对不能死。抢购没有关系，入园是我们最大的压力，
　　我们是靠新的系统提供了访问能力及可用性的支持，把类似这种场景支撑下来，其实缓存本身是可以支撑住的，但是如果滥用管理失控，可能碰到这种高可用的需求就废了。
　　还有一个是火车票系统，火车票查询量非常大，我们这主要是用了新系统的收缩容，到了晚上的时候查的人不多了，到了早上的时候特别多，他查询量是在一个高低跌荡的，所以我们可以根据访问的情况来弹性调度。
　　编辑推荐：架构技术实践系列文章（部分）：
欢迎举报抄袭、转载、暴力色情及含有欺诈和虚假信息的不良文章。
请先登录再操作
请先登录再操作
微信扫一扫分享至朋友圈
搜狐公众平台官方账号
生活时尚&搭配博主 /生活时尚自媒体 /时尚类书籍作者
搜狐网教育频道官方账号
全球最大华文占星网站-专业研究星座命理及测算服务机构
主演：黄晓明/陈乔恩/乔任梁/谢君豪/吕佳容/戚迹
主演：陈晓/陈妍希/张馨予/杨明娜/毛晓彤/孙耀琦
主演：陈键锋/李依晓/张迪/郑亦桐/张明明/何彦霓
主演：尚格?云顿/乔?弗拉尼甘/Bianca Bree
主演：艾斯?库珀/ 查宁?塔图姆/ 乔纳?希尔
baby14岁写真曝光
李冰冰向成龙撒娇争宠
李湘遭闺蜜曝光旧爱
美女模特教老板走秀
曝搬砖男神奇葩择偶观
柳岩被迫成赚钱工具
大屁小P虐心恋
匆匆那年大结局
乔杉遭粉丝骚扰
男闺蜜的尴尬初夜
客服热线：86-10-
客服邮箱：