唯品会-Redis架构演进-GOPS2016.pptx

唯品会大规模Redis存储架构演进;个人简介;目录;Redis; ;挑战;目录; ; ;自定义数据分布规则 无在线扩容能力 扩容过程对应用不透明 需要开发高可用方案 ;Twemproxy;提供数据分片算法，包括一致性哈希 兼容redis/mc协议和大部分redis命令 支持pipeline 支持mset/mget操作 架构复杂，成本较高 Redis层无法在线扩容 twemproxy缺陷 lvs层瓶颈，改用ospf模式？ ;1、为什么使用LB/LVS? 方便管理，部署和监控方面 依赖健康检查，剔除问题节点 权重调整，比如压测 2、如何解决Twemproxy的扩容能力不足？ 预分配充足的节点 改造Twemproxy，支持节点替换 ;主推redis cluster架构 架构简化 节约大量机器成本 运维管理简单化 系统瓶颈更少 大幅度性能提升;Tips;二次开发;为什么不实用Codis？;Redis Cluster;无中心架构 数据按照slot存储分布在多个redis实例上 增加slave做standby数据副本，用于failover，集群快速恢复 实现故障auto failover 亦可manual failover，为升级和迁移提供可操作方案 降低硬件成本和运维成本，提高系统的扩展性和可用性 ;;目录;进程cpu利用率，why? 单进程 QPS、命中率 内存 复制状态 客户端连接数 ;timeout 180 tcp-keepalive 300 repl-backlog-size 32M #默认1M，导致无法pysnc client-output-buffer-limit normal 512mb 256mb 60 client-output-buffer-limit slave 1024mb 256mb 120 ;rdb 还是aof？ 主库持久化还是从库？ Fork子线程时，前端出现请求超时。 磁盘配置 缓存是够需要持久化数据？;slow query严重影响服务的稳定性。 单个请求执行很长时间，其他客户端大量请求超时 比如常见的O(N)操作，hmget/lrang/keys等 管理操作命令，bgrewriteaof/bgsave时fork子线程时造成短暂的写入阻塞 隐藏的操作，big-key expired 持久化策略 ;cluster-node-timeout，默认15s，过小造成集群不稳定 cluster-require-full-coverage，集群是否可以部分可用？ 建议使用成熟稳定的redis-3.0.7版本，3.2.x新增代码较多 3.0.x后期版本数据迁移更快，migrate操作实现单次迁移多个key 提醒开发注意客户端驱动参数默认值，比如JedisCluster里面DEFAULT_MAX_REDIRECTIONS = 5 ;目录;Cache和Storage;常见问题： 1）数据miss或者异常求处理无后续处理逻辑 2）db同步cache数据更新策略 3??重试机制 4）回源惊群问题和过载保护机制;目的： 缓存热点数据 减少穿透到DB的请求 数据闭环 ;探索内存+磁盘存储模式，降低生产成本; QA Thanks！ ;GOPS2016 全球运维大会更多精彩