Redis Cluster

面试题 生产环境中的 redis 是怎么部署的？ 面试官心理分析 看看你了解不了解你们公司的 redis 生产集群的部署架构，如果你不了解，那么确实你就很失职了，你的 redis 是主从架构？集群架构？用了哪种集群方案？有没有做高可用保证？有没有开启持久化机制确保可以进行数据恢复？线上 redis 给几个 G 的内存？设置了哪些参数？压测后你们 redis 集群承载多少 QPS？ 兄弟，这些你必须是门儿清的，否则你确实是没好好思考过。 面试题剖析 redis cluster，10 台机器，5 台机器部署了 redis 主实例，另外 5 台机器部署了 redis 的从实例，每个主实例挂了一个从实例，5 个节点对外提供读写服务，每个节点的读写高峰qps可能可以达到每秒 5 万，5 台机器最多是 25 万读写请求/s。 机器是什么配置？32G 内存+ 8 核 CPU + 1T 磁盘，但是分配给 redis 进程的是10g内存，一般线上生产环境，redis 的内存尽量不要超过 10g，超过 10g 可能会有问题。 5 台机器对外提供读写，一共有 50g 内存。 因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis 从实例会自动变成主实例继续提供读写服务。 你往内存里写的是什么数据？每条数据的大小是多少？商品数据，每条数据是 10kb。100

前言 我们都知道，Redis和Memcached都是内存数据库，它们的访问速度非常之快。但我们在开发过程中，这两个内存数据库，我们到底要如何选择呢？它们的优劣都有哪些？ 为什么现在看Redis要比Memcached更火一些？ 这篇文章，我们就从各个方面来对比这两个内存数据库的差异，方便你在使用时，做出最符合业务需要的选择。 要分析它们的区别，主要从以下几个方面对比： 线程模型 数据结构 淘汰策略 管道与事务 持久化 高可用 集群化 线程模型 要说性能，必须要分析它们的服务模型。 Memcached处理请求采用多线程模型，并且基于IO多路复用技术，主线程接收到请求后，分发给子线程处理。 这样做好的好处是，当某个请求处理比较耗时，不会影响到其他请求的处理。 当然，缺点是CPU的多线程切换必然存在性能损耗，同时，多线程在访问共享资源时必然要加锁，也会在一定程度上降低性能。 Redis同样采用IO多路复用技术，但它处理请求采用是单线程模型，从接收请求到处理数据都在一个线程中完成。 这意味着使用Redis，一旦某个请求处理耗时比较长，那么整个Redis就会阻塞住，直到这个请求处理完成后返回，才能处理下一个请求，使用Redis时一定要避免复杂的耗时操作。 单线程的好处是，少了CPU的上下文切换损耗，没有了多线程访问资源的锁竞争，但缺点是无法利用CPU多核的性能。 由于Redis是内存数据库

来自：小姐姐味道 redis功能强大，数据类型丰富，再快的系统，也经不住疯狂的滥用。通过禁用部分高风险功能，并挂上开发的枷锁，业务更能够以简洁、通用的思想去考虑问题，而不是绑定在某种实现上。 Redis 根据不同的用途，会有不同的持久化策略和逐出策略，所以，在使用和申请 Redis 集群前，请明确是用来做缓存还是存储。redis 的集群有主从和 cluster 两种模式，各有优缺点。以下规范不区分集群模式，我们分别从使用场景和操作限制两方面说明。 使用规范 冷热数据区分 虽然 Redis支持持久化，但将所有数据存储在 Redis 中，成本非常昂贵。建议将热数据 (如 QPS超过 5k) 的数据加载到 Redis 中。低频数据可存储在 Mysql、 ElasticSearch中。 业务数据分离 不要将不相关的数据业务都放到一个 Redis中。一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复。 消息大小限制 由于 Redis 是单线程服务，消息过大会阻塞并拖慢其他操作。保持消息内容在 1KB 以下是个好的习惯。严禁超过 50KB 的单条记录。消息过大还会引起网络带宽的高占用，持久化到磁盘时的 IO 问题。 连接数限制 连接的频繁创建和销毁，会浪费大量的系统资源，极限情况会造成宿主机当机。请确保使用了正确的 Redis 客户端连接池配置。 缓存 Key

缓存 缓存的作用： 高并发、高性能 高性能：查询速度快 高并发：缓存是走内存的，内存天然就支撑高并发 常见缓存问题： 缓存与数据库双写不一致 缓存雪崩、缓存穿透、缓存击穿 缓存并发竞争 如何保证缓存和数据库一致性： 使用串行化，即：将读请求和写请求放到一个内存队列中。 串行化可以保证缓存与数据库一直，但是会导致系统吞吐量大幅度降低。非严格要求，不要串行化。 经典缓存+DB读写模式 》读：先读缓存，没有读取DB,读出来放入缓存。 》更新：先更新DB,再 删除 缓存。 缓存雪崩 请求量大时，缓存此时也跌机了，导致大量请求直接请求DB,带着DB也跌机了。 缓存雪崩的事前事中事后的解决方案： 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。 事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。 缓存穿透 缓存中查询不到，大量的请求直接查询DB. 解决方案： 每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN 。然后设置一个过期时间，这样的话，下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。 缓存击穿 某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况

一、简介 1.1 Redis是什么 Redis是一个开源的，使用ANSI C 编写，高性能的Key-Value的NoSQL数据库。 1.2 Redis特点 （1）基于内存 （2）可持久化数据 （3）具有丰富的数据结构类型，适应非关系型数据的存储需求 （4）支持绝大多数主流开发语言，如C、C++、Java、Python、R、JavaScript等。 （5）支持集群模式，高效、稳定。 1.3 数据模型（重点） （1）键值对形式。 （2）Redis的数据结构类型，指的就是Redis值的结构类型。 1.4 Redis作用 （1）本质是数据库，能存储数据。 Redis能灵活处理非关系型数据的读、写问题，是对MySQL等关系型数据库的补充。 新浪微博就是使用Redis集群做数据库。 （2）缓存数据。 所谓缓存，就是将数据加载到内存中后直接使用，而不是每次都通过IO流从磁盘上读取。好处：读写效率高。 而Redis则是将数据直接存储在内存中，只有当内存空间不足时，将部分数据持久化到磁盘上。 二、安装 1.1 说明 Redis官方只提供了源码，并没有提供经过编译之后的安装包。 因此，安装Redis，要先编译、后安装。（即源码安装方式） 1.2 redis安装步骤 # 安装步骤 cd /usr/ local /src wget http://download.redis.io/releases

面试题 redis 集群模式的工作原理能说一下么？在集群模式下，redis 的 key 是如何寻址的？分布式寻址都有哪些算法？了解一致性 hash 算法吗？ 面试官心理分析 在前几年，redis 如果要搞几个节点，每个节点存储一部分的数据，得 借助一些中间件 来实现，比如说有 codis ，或者 twemproxy ，都有。有一些 redis 中间件，你读写 redis 中间件，redis 中间件负责将你的数据分布式存储在多台机器上的 redis 实例中。 这两年，redis 不断在发展，redis 也不断有新的版本，现在的 redis 集群模式，可以做到在多台机器上，部署多个 redis 实例，每个实例存储一部分的数据，同时每个 redis 主实例可以挂 redis 从实例，自动确保说，如果 redis 主实例挂了，会自动切换到 redis 从实例上来。 现在 redis 的新版本，大家都是用 redis cluster 的，也就是 redis 原生支持的 redis 集群模式，那么面试官肯定会就 redis cluster 对你来个几连炮。要是你没用过 redis cluster，正常，以前很多人用 codis 之类的客户端来支持集群，但是起码你得研究一下 redis cluster 吧。 如果你的数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就几个 G

主从复制的作用主要包括： 1、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。 2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。 3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点） 分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。 4、读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量； 5、高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。 从节点开启主从复制，有3种方式： （1）配置文件 在从服务器的配置文件中加入：slaveof <masterip> <masterport> （2）启动命令 redis-server启动命令后加入 --slaveof <masterip> <masterport> （3）客户端命令 Redis服务器启动后，直接通过客户端执行命令：slaveof <masterip> <masterport>，则该Redis实例成为从节点。 通过 info replication

# Redis configuration file example. # # Note that in order to read the configuration file, Redis must be # started with the file path as first argument: # # ./redis-server /path/to/redis.conf # Note on units: when memory size is needed, it is possible to specify # it in the usual form of 1k 5GB 4M and so forth: # # 1k => 1000 bytes # 1kb => 1024 bytes # 1m => 1000000 bytes # 1mb => 1024*1024 bytes # 1g => 1000000000 bytes # 1gb => 1024*1024*1024 bytes # # units are case insensitive so 1GB 1Gb 1gB are all the same. ################################## INCLUDES ###################################

https://www.cnblogs.com/xiaodf/p/11002184.html 本文旨在介绍一种在Redis集群模式下提供Pipeline批量操作的功能。 基本思路就是根据redis cluster对数据哈希取模的算法， 先计算数据存放的slot位置, 然后根据不同的节点将数据分成多批， 对不同批的数据进行单点pipeline处理。 但是需要注意的是，由于集群模式存在节点的动态添加删除，且client不能实时感知（只有在执行命令时才可能知道集群发生变更）， 因此，该实现不保证一定成功，建议在批量操作之前调用 refreshCluster () 方法重新获取集群信息。 应用需要保证不论成功还是失败都会调用close() 方法，否则可能会造成泄露。 如果失败需要应用自己去重试，因此每个批次执行的命令数量需要控制，防止失败后重试的数量过多。 基于以上说明，建议在集群环境较稳定（增减节点不会过于频繁）的情况下使用，且允许失败或有对应的重试策略。 来源： oschina 链接： https://my.oschina.net/u/3847203/blog/4459078

从实践中检验“真理” ​通过上一篇《 大数据基础-求锤得锤，你要的一致性hash来了(上）[附代码] 》的讲解，我们已经掌握了一致性hash的基本原理，其路由分片策略在类p2p模型架构中是非常典型的(之前提到的redis cluster也是p2p协议的一种实现)，在节点宕机时的影响很小，只影响到一个分片。只看原理的话确实也就这么多了，那么其实际效果究竟是否和原理中完全一致？是否还存在一些问题呢？我们来逐一验证下。 写这个系列文章以后，从后台看到收藏次数很多，我本身也是很开心，说明很多小伙伴还是有所收获的，也希望能在收藏之余，来个 三连哈 !!! 节点扩容测试 集群4个节点[192.168.1.1~192.168.1.4]，扩容第5个节点[192.168.1.5]时的key迁移信息，查看待迁移key的信息。 print '上线一个节点，需要迁移节点个数:{}'.format(len(list(set(addNodeMap).difference(set(oldMap))))) print '需要迁移的key-node信息:',list(set(addNodeMap).difference(set(oldMap))) 扩容结果：需要迁移部分key 到新扩容的节点192.168.1.5上，这里总计有3个key 上线一个节点，需要迁移节点个数:3 需要迁移的key-node信息: [