Redis5.0优化点中有内存使用统计报告的优化，下面分别在Redis4的版本和Redis5的版本中分别使用info memory命令来查看返回结果，进行对比。 Redis4.0.14 INFO MEMORY结果 [root@redis-7-105 conf]# redis-cli -p 7008 info memory # Memory used_memory:14835120 used_memory_human:14.15M used_memory_rss:24780800 used_memory_rss_human:23.63M used_memory_peak:14884304 used_memory_peak_human:14.19M used_memory_peak_perc:99.67% used_memory_overhead:1941912 used_memory_startup:786640 used_memory_dataset:12893208 used_memory_dataset_perc:91.78% total_system_memory:1019572224 total_system_memory_human:972.34M used_memory_lua:37888 used_memory_lua_human:37.00K maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction mem_fragmentation_ratio:1.67 mem_allocator:jemalloc-4.0.3 active_defrag_running:0 lazyfree_pending_objects:0 ```` - **Redis5.0.9 INFO MEMORY结果** shell [root@reids-7-104 data]# redis-cli -p 7007 info memory Memory used_memory:13771704 used_memory_human:13.13M used_memory_rss:27258880 used_memory_rss_human:26.00M used_memory_peak:13812512 used_memory_peak_human:13.17M used_memory_peak_perc:99.70% used_memory_overhead:882422 used_memory_startup:792456 used_memory_dataset:12889282 used_memory_dataset_perc:99.31% allocator_allocated:13982280 allocator_active:15417344 allocator_resident:24666112 total_system_memory:1019572224 total_system_memory_human:972.34M used_memory_lua:37888 used_memory_lua_human:37.00K used_memory_scripts:0 used_memory_scripts_human:0B number_of_cached_scripts:0 maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction allocator_frag_ratio:1.

原文地址：https://juejin.cn/post/7028439051308892167 一、背景 最近在看redis这方面的知识，发现在redis5中产生了一种新的数据类型Stream，它和kafka的设计有些类似，可以当作一个简单的消息队列来使用。 二、redis中Stream类型的特点 支持持久化。streams能持久化存储数据，不同于pub/sub机制和list 消息被消费后就会被删除，streams消费过的数据会被持久化的保存在历史中。 支持消息的多播、分组消费。 这一点跟 pub/sub有些类似。 支持消息的有序性，可以通过消息的ID来控制消息的排序。 支持消费者组。streams 允许同一消费组内的消费者竞争消息，并提供了一系列机制允许消费者查看自己的历史消费消息。并允许监控streams的消费者组信息，消费者组内消费者信息，也可以监控streams内消息的状态。 三、Stream的结构 解释： 1. 消费者组：Consumer Group,即使用XGROUP CREATE命令创建的，一个消费者组中可以存在多个消费者，这些消费者之间是竞争关系。 1. 同一条消息，只能被这个消费者组中的某个消费者获取。 2. 多个消费者之间是相互独立的，互不干扰。 2. 消费者： Consumer 消费消息。 3. last_delivered_id： 这个id保证了在同一个消费者组中，一个消息只能被一个消费者获取。每当消费者组的某个消费者读取到了这个消息后，这个last_delivered_id的值会往后移动一位，保证消费者不会读取到重复的消息。 4. pending_ids：记录了消费者读取到的消息id列表，但是这些消息可能还没有处理，如果认为某个消息处理，需要调用ack命令。这样就确保了某个消息一定会被执行一次。 5. 消息内容：是一个键值对的格式。 6. Stream 中 消息的 ID： 默认情况下，ID使用 * ，redis可以自动生成一个，格式为 时间戳-序列号，也可以自己指定，一般使用默认生成的即可，且后生成的id号要比之前生成的大。 四、Stream的命令 1、XADD 往Stream末尾添加消息 1、命令格式 xadd key [NOMKSTREAM] [MAXLEN|MINID [=|~] threshold [LIMIT count]] *|ID field value [field value ...] xadd命令解释 2、举例 xadd 命令 返回的是数据的id, xx-yy (xx指的是毫秒数,yy指的是在这个毫秒内的第几条消息)

Redis-trib支持的操作： # redis-trib.rb help Usage: redis-trib <command> <options> <arguments ...> create host1:port1 ... hostN:portN --replicas <arg> check host:port info host:port fix host:port --timeout <arg> reshard host:port --from <arg> --to <arg> --slots <arg> --yes --timeout <arg> --pipeline <arg> rebalance host:port --weight <arg> --auto-weights --use-empty-masters --timeout <arg> --simulate --pipeline <arg> --threshold <arg> add-node new_host:new_port existing_host:existing_port --slave --master-id <arg> del-node host:port node_id set-timeout host:port milliseconds call host:port command arg arg .. arg import host:port --from <arg> --copy --replace help (show this help) For check, fix, reshard, del-node, set-timeout you can specify the host and port of any working node in the cluster.

Introduction to the Redis 5 release Redis 5 is a release focused on a few important features. While Redis 4 was very very focused on operations, Redis 5 changes are mostly user-facing, with the implementation of new data types and operations on top of existing types. The following are the major features of this release: Redis5是一个聚焦到几个重要改进的版本。Redis4是非常关注操作，Redis5改进是非常关注用户界面， 新增了新的数据类型的实现和现有数据类型的相关操作。 The new Stream data type. https://redis.io/topics/streams-intro New Redis modules APIs: Timers, Cluster and Dictionary APIs.

Lettuce 已支持 Redis6 客户端缓存 简介： 在 redis 6.0 版本中，已经默认支持了客户端缓存功能，Java 中主流的连接客户端 lettuce 在最新的快照版本 (6.0.0.BUILD-SNAPSHOT) 已经提供支持。 下边就通过代码来体验一下客户端缓存的神奇功能。 Redis 客户端缓存 缓存的解决方案一般有两种： 【L1】 内存缓存（如 Caffeine、Ehcache） —— 速度快，进程内可用，但重启缓存丢失，出现缓存雪崩的问题。 【L2】集中式缓存（如 Redis）—— 可同时为多节点提供服务，但高并发下，带宽成为瓶颈。 业内有很多开源框架来解决以上问题，既能有 L1 速度，并且拥有 L2 集群态。如下 J2Cache 两级缓存框架 hotkey 热点数据实时同步 在 redis 6.0 版本中，已经默认支持了客户端缓存功能，Java 中主流的连接客户端 lettuce 在最新的快照版本 (6.0.0.BUILD-SNAPSHOT) 已经提供支持。 下边就通过代码来体验一下客户端缓存的神奇功能。 Redis 6.0 安装 安装 redis 6,这里通过 Docker 安装命令如下 docker run --name redis6 -p 6379:6379 --restart=always -d redis:6.0.6 Jar 依赖 注意： 这里使用 lettuce 客户端，注意当前使用 6.0 的快照版本 ，需要在 pom 增加 lettuce 快照仓库

背景 传输层安全性协议（英语：Transport Layer Security，缩写作TLS），及其前身安全套接层（Secure Sockets Layer，缩写作SSL）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。Redis6支持TLS，并且支持SSL。 1.目录设置 redis源码解压目录 /app/cachecloud/redis 测试环境：CENTOS7.3 redis版本：6.2.7 2.编译redis 要测试TLS，要在编译时选择编译TLS，跳转到redis源码解压目录，执行 make BUILD_TLS=yes 编译过程中出现如下错误： ssl.c:45:25: 致命错误：openssl/ssl.h：没有那个文件或目录 #include <openssl/ssl.h> 这时要中断编译，先安装openssl yum install openssl-devel 安装好 open-ssl后再次执行make BUILD_TLS=yes命令即可编译成功 3.生成测试证书 在源码目录执行生成证书脚本 [root@redis-7-109 ~]# cd /app/cachecloud/redis [root@redis-7-109 redis]# ./utils/gen-test-certs.sh Generating RSA private key, 4096 bit long modulus …… 生成后在tests/tls目录下可以看到生成的证书文件 [root@redis-7-109 tls]# ls -l /app/cachecloud/redis/tests/tls/ 总用量 44 -rw-r--r--. 1 root root 1879 7月 11 11:30 ca.crt -rw-r--r--. 1 root root 3243 7月 11 11:30 ca.

ACLs 权限控制  Redis 6开始支持ACL，该功能通过限制对命令和key的访问来提高安全性。ACL的工作方式是在连接之后，要求客户端进行身份验证（用户名和有效密码）；如果身份验证阶段成功，则连接与指定用户关联，并且该用户具有限制。 在默认配置中，Redis 6的工作方式与Redis的旧版本完全相同，每个新连接都能够调用每个可能的命令并访问每个键，因此ACL功能与旧版本向后兼容。客户和应用程序。依旧使用requirepass配置密码的，但现在只是为默认用户设置密码。 4.1 ACL使用 1) ACL <subcommand> arg arg ... arg. Subcommands are: 2) LOAD -- Reload users from the ACL file. 3) SAVE -- Save the current config to the ACL file. 4) LIST -- Show user details in config file format. 5) USERS -- List all the registered usernames. 6) SETUSER <username> [attribs ...] -- Create or modify a user. 7) GETUSER <username> -- Get the user details.

官方文档地址：https://redis.io/docs/manual/security/acl/ ACL Redis access control list The Redis ACL, short for Access Control List, is the feature that allows certain connections to be limited in terms of the commands that can be executed and the keys that can be accessed. The way it works is that, after connecting, a client is required to provide a username and a valid password to authenticate. If authentication succeeded, the connection is associated with a given user and the limits the user has.