唯品会大规模 Redis Cluster 的生产实践

  • 时间:
  • 浏览:1
  • 来源:大发彩神在线计划—大发彩神计划怎么来的

3)设置repl-backlog-size 64mb。默认值是1M,当写入量很大时,backlog溢出会原困增量好友克隆不成功。

亦可manual failover,为升级和迁移提供可操作方案。

redis建议使用pipeline和multi-keys操作,减少RTT次数,提高请求下行效率 。

合理的连接池大小。

github上讨论的结果是线程运行retry。

图上不到master节点(slave略去),所有节点构成另另4个完整图,slave节点在集群中与master不到角色和功能的区别。

实现故障auto failover。节点之间通过gossip协议交换情况表信息;投票机制完成slave到master角色的提升。

不扩容时集群非常稳定。

作为后端应用的存储,数据来源主要以下并算不算最好的措施:

重试时间应该大于cluster-node-time时间

还是强调容错,某些时要针对cluster,所有的应用设计都适用。

redis cluster GA过后,亲戚亲戚朋友就开使英语 上线使用。最初是3.0.2 版本,后面 少许使用3.0.3 ,上个月开使英语 使用3.0.7版本。

答:fork不友好

区分redis 和 cluster的使用,一方面是数据分片引起的;自己面,与client的实现支持相关。

正确处理使用阻塞操作,不建议使用事务。

开发规范,使亲戚亲戚朋友的开发按照最优的最好的措施使用nosql。

架构僵化 ,层次多。包括lvs、twemproxy、redis、sentinel和其控制层线程运行。

节点会肯能某些原困所处阻塞(阻塞时间大于clutser-node-timeout),被判断下线。某些failover是没法必要,sentinel也所处某些切换场景。

所处哪些坑?

正确处理产生hot-key,原困节点成为系统的短板。

zabbix作为主要的监控数据埋点工具。

cluster 一般数据量大, 单个cluster集群在几八个GB到上TB级别内存存储量。

本文是陈辉同学在Redis中国用户组给亲戚亲戚朋友分享redis cluster的生产实践。

第3次要:redis cluster的稳定性,应用性性性心智性心智成熟是什么 期期度,踩到过哪些坑,怎样正确处理哪些大问题?这次也不亲戚亲戚朋友比较关系的内容。

正确处理使用multi-keys操作,比如mset/mget. multi-key操作某些客户端没法支持实现。

业务高峰期请求量急剧上升,几倍的读写量增加,时要多个redis实例承担业务的读写压力。

Jedis另另4个连接创建异常大问题(fixed):

https://github.com/xetorthio/jedis/issues/1252

客户端的不性性性心智性心智成熟是什么 期期,影响应用的稳定性,提高开发难度。

1)Github:

https://github.com/vipshop/vire

1、生产应用场景

2、存储架构演变3、应用最佳实践4、运维经验总结

Tips

redis集群内部内部结构最多只允许另另4个slot所处迁移情况表,不到并发的迁移slots。

关于这4次要的内容介绍:

b) 正确处理使用会引起长时间阻塞的命令,比如save/flushdb等阻塞操作,肯能keys pattern某些慢查询。

本文转自    鹏爱   51CTO博客,原文链接:

某些是在setup集群的过后所处过的另另4个大问题,bind 0.0.0.0我我觉得所处某些安全性大问题,某些某些 是比较简单通用的正确处理最好的措施。

key命名规则。

正确处理最好的措施:启动时指定网卡ipv4地址,都可不还上能 不到是0.0.0.0,配置文件中加上:bind 0.0.0.0

正确处理产生big-key,原困网卡打爆、慢查询。

MySQL →  Redis Cluster,Java/C++线程运行。

能不到作为cache和storage的proxy(by auto-eject)。

能不到节约少许的硬件资源,亲戚亲戚朋友的Lvs + Twemproxy层 使用了近上千台物理机器。

sharding逻辑对开发透明,读写最好的措施和单个redis一致。

rename-command FLUSHDB REDIS_FLUSHDB

基本思想来源于pt-query-degest,通过分析tcp应答报文产生日志。flume agent + kafka埋点,spark实时计算,hbase作为存储。最终得到hotquery/slowquery,request source等性能数据。

答:亲戚亲戚朋友没法读写分离的使用,读写时要maste;集群太大,管理僵化 ;此外,亲戚亲戚朋友也做了分片,没法做读写分离的必要;且亲戚亲戚朋友几乎是一主一从节点配置

redis cluster不建议使用pipeline和multi-keys操作,减少max redirect产生的场景。

文章来源:http://h2ex.com/1117?utm_source=tuicool&utm_medium=referral

开发DB响应时间监控工具Titan。

答:亲戚亲戚朋友重启升级从2.8.17到3.0.3/3.0.7没法任何的异常。3.0到3.2亲戚亲戚朋友目前还没法实际升级操作过。

Agent最好的措施上报硬软件信息。

1)大幅度提升单个proxy的吞吐量,线程运行数可配置。

2)压测情况表下,20线程运行达到400w+qps,最优6线程运行达到29w。

3)完整兼容twemproxy。

4)github:

https://github.com/vipshop/twemproxies

2 * 1Gbps 网卡的lvs机器,最大能支撑17万pps。

具体大问题:redis启动正常,节点的协议端口不到ipv6 socket创建正常。异常节点也无法加入到集群中,也无法获取epoch。

Puppet管理和埋点标准化的配置文件、公用的任务计划、软件包、运维工具。

这是亲戚亲戚朋友的生产应用场景,主某些某些 后端业务的存储,目前没法作为cache使用的场景。

rename-command FLUSHALL REDIS_FLUSHALL

rename危险操作:

总体来说,redis cluster肯能非常稳定了,某些某些 要注意某些应用中的小大问题,下面是八个坑,亲戚亲戚朋友注意了.

另外亲戚亲戚朋友也开使英语 测试3.2.0版本,内存空间优化很大。

redis cluster的稳定性怎样?

陈群,目前在唯品会主要负责redis/hbase的运维和开发支持工作,也参与工具开发工作。

答:我我觉得所处这方面的大问题,这方面支持时要客户端的支持,某些某些 jedis的作者某些某些 大让你支持pipeline肯能某些multi key操作。肯能是大批量的操作,能不到用线程运行提高客户端的吞吐量。

开发实时性能dashboard,对开发提供查询。

client实现僵化 ,驱动要求实现smart client,缓存slots mapping信息并及时更新。

retry时间应该大于failover 时间。

系统瓶颈更少。lvs层网卡和pps吞吐量瓶颈;对于请求长度较大的业务,twemproxy单节点性能低。

总结下,亲戚亲戚朋友选择redis cluster主要这两点原困:简单、扩展性。另外,亲戚亲戚朋友用cluster取代twemproxy集群,三层架构我我觉得是很令人头疼,僵化 、瓶颈多、管理不方面。

连接大问题是redis开发使用中最常见的大问题,connection timeout/read timeout,还有borrow connection的大问题。

连接肯能请求异常,进行连接retry和reconnect。

1)在线实时迁移

2)redis/twemproxy/cluster 异构集群之间相互迁移。

3)github:https://github.com/vipshop/redis-migrate-tool

这是twemproxy的架构,客户端直接连接最后面 的lvs(LB),第二层是同构的twemproxy节点,下面的redis master节点以及热备的slave节点,另外还有独立的sentinel集群和切换控制线程运行,twemproxy先介绍到这里。

降低硬件成本和运维成本,提高系统的扩展性和可用性。

1)设置系统参数vm.overcommit_memory=1,能不到正确处理bgsave/aofrewrite失败。

twemproxy也支持pipeline, 支持次要的multi-key能不到操作。

数据由离线/实时job生成, 读写请求量大, 对读写性能也要求高。

快速释放使用完的连接。

redis cluster在唯品会主要应用于后端业务,用作内存存储服务。主要大数据实时推荐/ETL、风控、营销三大业使用。

2)设置timeout值大于0,能不到使redis主动释放空闲连接。

redis-3.0.6版本过后migrate操作是单个key逐一操作。从redis-3.0.6开使英语 ,支持单次迁移多个key。

慢查询。keys *、大key的操作、O(N)操作

单机部署多个redis,借促使zabbix discovery。

CMDB管理所有的资源信息。

develop guideline & best practice

合理的心跳检测时间。

max redirt issues:https://github.com/xetorthio/jedis/issues/1238

无中心架构,各个节点度等。slave节点提供数据冗余,master节点异常时提升为master。

流量高的系统,proxy节点数和redis个数接近。

资源申请自助服务化。

http://blog.51cto.com/pengai/1837266

a) 默认的cluster-node-timeout为15s,能不到适当增大;

慢查询,线程运行运行cpu 400%、客户端请求调快,甚至超时。

第1、2次要:介绍redis cluster在唯品会的生产应用场景,以及存储架构的演变。

Failover能力和高可用性。

Jedis参数优化调整:增大jedis中的‘DEFAULT_MAX_REDIRECTIONS’参数,默认值是5.

无中心架构。

目前亲戚亲戚朋友在线有生产几八个cluster集群,约2千个instances,单个集群最大达到2400+instances。

在2014年7月,为了准备当时的814撒娇节大促销活动,亲戚亲戚朋友把单个redis的服务迁移到twemproxy上。twemproxy在后端快速完成数据分片和扩容。为了正确处理再次扩容,亲戚亲戚朋友静态分配足够多的资源。

少了lvs和twemproxy层,读写性能提升明显。响应时间从400-400us减少到400-400us。

本次分享内容如下:

存活检测机制所处问题

redis 存活检测机制肯能肯能master 节点上慢查询、阻塞式命令、肯能其它的性能大问题原困长时间没法响应,某些节点会认为所处failed情况表,并进行切换。某些切换是没必要的。

redis-trib.rb reshard肯能执行中断,用redis-trib.rb fix修复集群情况表。

下面简单对比下并算不算架构,解析下亲戚亲戚朋友的优缺点。

数据按照slot存储分布在多个redis实例上。

主要正确处理server端维持少许的连接。

资源申请自助服务。

redis-trib.rb支持从单个redis迁移数据到cluster集群中。

主要使用的redis-trib.rb reshard来完成数据迁移。

业务需求变化快, schema变化频繁。肯能使用MySQL作为存储,没法肯能是频繁的DLL变更,某些某些 时要做online schema change。

扩容resharding过后,早期版本的Jedis端有后会总出 “max-redirect”异常。

分析Jedis源码,请求重试次数达到了上限,仍然没法请求成功。两方面分析:redis连接不上?还是集群节点信息不一致?

4)client buffer参数调整

client-output-buffer-limit normal 256mb 128mb 400

client-output-buffer-limit slave  512mb  256mb 1400

大促销活动时扩容频繁。

过后,twemproxy暴露出来的系统瓶颈某些某些,资源使用某些某些,也所处一定的浪费。亲戚亲戚朋友决定用redis cluster取代某些僵化 的三层架构。

目前仅JedisCluster相对性性性心智性心智成熟是什么 期期,异常正确处理次要还不完善,比如常见的“max redirect exception”。

第4次要:简单介绍大规模运营的某些经验,包括部署、监控、管理以及redis工具开发。

肯能申请合理,一键即可完成cluster集群部署。

能不动手的,就坚决不动手,另外,监控数据对开发开发有点儿要,让亲戚亲戚朋友了解自己服务性能,某些某些 开发会更早发现集群的某些异常行为,比如数据不过期某些大问题,运维就讲没法多了,后面 是干货中的干货,由deep同学开发的2个实用工具。

TTL, 设置合理的ttl,释放内存。正确处理少许key在同一时间段过期,我我觉得redis肯能做了某些某些优化,仍然会原困请求调快。

1)批量更改集群参数

2)clusterrebalance

3)某些某些功能,具体看github :

https://github.com/deep011/redis-cluster-tool

Kafka → Redis Cluster,Storm/Spark实时

增加slave做standby数据副本,用于failover,使集群快速恢复。

本次要包括内容如下:

redis-trib.rb支持resharding/rebalance,分配权重。

阻塞的命令。比如save/flushall/flushdb

Hive →  Redis Cluster,  MapReduce线程运行

cluster的架构如下:

在线水平扩展能力,都都可不还上能 正确处理亲戚亲戚朋友少许的扩容需求。

cluster用于取代当前twemproxy三层架构,作为通用的存储架构。redis cluster能不到大幅度僵化 亲戚亲戚朋友的存储架构,也正确处理twemproxy架构无法在线扩容节点的大问题。

亲戚亲戚朋友肯能开使英语 使用3.0.7版本,某些某些3.2.0修复的bug肯能backport到某些版本。

架构演变讲完了,开使英语 讲第三次要,也是亲戚亲戚朋友最感兴趣的一次要.

后面 2点不算坑把,算不算所处问题,tips也很实用。开使英语 分享下最佳实践。

答:能不到通过某些最好的措施,某些还在探究阶段,但目标是不需要fork

标准化基础设置。机型、OS内核参数、软件版本。

我我觉得cluster不保证主从数据强一致性,某些某些 后端业务都都可不还上能 容忍failover后少许的数据丢失。

rename-command KEYS REDIS_KEYS

取代twemproxy三层架构,系统僵化 性降低。

2)欢迎共同参与媒体合作开发,这是亲戚亲戚朋友在开发中的项目,希望亲戚亲戚朋友都都可不还上能 提出好的意见。

管理成本和硬件成本很高。

Redis层仍然扩容能力差,预分配足够的redis存储节点。