Redis

1.版本： Redis官网上有Linux版本，Redis官网： https://redis.io/download GitHub上有Windows版本，地址是： https://github.com/MicrosoftArchive/redis/tags 2.安装步骤（引入外文）： Linux: https://www.jianshu.com/p/bc84b2b71c1c Windows: https://blog.csdn.net/leisure_life/article/details/82078233 3.注意： Linux环境下： (如果在安装时报错：/bin/sh: cc: command not found 说明没有安装gcc) 安装gcc：root用户下：yum install gcc gcc-c++ 深入学习传送门： 1.Redis 安装前的Linux环境准备： https://blog.csdn.net/u010327957/article/details/52507131 （包括虚拟机安装） 2.Redis入门学习： https://www.imooc.com/learn/839 （Redis和Jedis使用的入门级教程） 来源： oschina 链接： https://my.oschina.net/u/4391021/blog/3580828

Redis集群设计包括 2部分：哈希 Slot和节点主从 节点主从： 主从设计不算什么新鲜玩意，在数据库中我们也经常用主从来做读写分离，直接上图： 图上能看得到的信息： 1， 只有1个Master，可以有N个slaver，而且Slaver也可以有自己的Slaver，由于这种主从的关系决定他们是在配置阶段就要指定他们的上下级关系，而不是Zookeeper那种平行关系是自主推优出来的。 2， 读写分离，Master只负责写和同步数据给Slaver，Slaver承担了被读的任务，所以Slaver的扩容只能提高读效率不能提高写效率。 3， Slaver先将Master那边获取到的信息压入磁盘，再load进内存，client端是从内存中读取信息的，所以Redis是内存数据库。 当一个新的Slaver加入到这个集群时，会主动找Master来拜码头，Master发现新的小弟后将全量数据发送给新的Slaver，数据量越大性能消耗也就越大，所以尽量避免在运行时做Slaver的扩容。 简单总结下主从模式的设计： 优点：读写分离，通过增加Slaver可以提高并发读的能力。 缺点：Master写能力是瓶颈。 虽然理论上对Slaver没有限制但是维护Slaver开销总将会变成瓶颈。 Master的Disk大小也将会成为整个Redis集群存储容量的瓶颈。 哈希Slot： 这个艺名看起来很文艺

都 2020 年了 还没用过 微服务 吗？中台架构还只是听说过？ 面试的时候对于分布式高并发高可用架构问题的回答总是不能让面试官满意？ 微服务架构很多，到底用Spring Cloud 还是 Dubbo ？ Spring Cloud Alibaba 与 Spring Cloud Netflix 如何选择？ 互联网微服务中台项目究竟有多少细节？ 让你架构一个能支撑淘宝千亿级流量的电商平台你知道如何着手吗？ 那么你缺乏这两个字 实 战 消除痛点、解决面试、积累实战经验 欢迎你参加图灵学院诸葛老师 微服务架构 特训营 本号粉丝： 免 费 四天你将学到 快速 · 实战微服务架构，了解各个组件的作用 极简 · 从点到面，内容绝不拖泥带水 实战 · 构建微服务项目 架构 · 阿里双十一微服务架构设计 健壮 · 互联网项目常用中间件服务 做到 · 从传统项目转向微服务互联网系统架构 吊打 · 面试官，独家解析淘宝网微服务中台架构 诸葛老师是谁？ 图灵学院联合创始人 前唯品会京东资深架构师 帮你积累亿级流量，千万级QPS，百万级TPS互联网系统线上微服务架构经验，从此开启涨薪升级之旅！ 让你在简历上可以增加高并发高可用系统微服务架构经验，从此横扫一切关于微服务Spring Cloud底层架构的面试问题，成为一个行走的offer收割机！ 训练营时间： 8月17日-8月20日，20:00 开营前

reids集群架构图： 在这个图中，每一个蓝色的圈都代表着一个 redis 的服务器节点。它们任何两个节点之间都是相互连通的 (Gossip 协议 ) 。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。 　　那么 redis 是怎么做到的呢？首先，在 redis 的每一个节点上，有一个 插槽（ slot ） 可以理解为是一个可以存储两个数值的一个变量这个变量的取值范围是： 0-16383 。还有一个就是 cluster 我个人把这个 cluster 理解为是一个集群管理的插件。当我们的存取的 key 到达的时候， redis 会根据 CRC 16 的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。 　　还有就是因为如果集群的话，是有好多个 redis 一起工作的，那么，就需要这个集群不是那么容易挂掉，所以呢，理论上就应该给集群中的每个节点至少一个备用的 redis 服务。这个备用的 redis 称为从节点（ slave ）。那么这个集群是如何判断是否有某个节点挂掉了呢？ 首先要说的是，每一个节点都存有这个集群所有主节点以及从节点的信息。 　　它们之间通过互相的 ping-pong

redis-rdb-tools安装部署及使用 redis内存分析工具redis-rdb-tools安装部署 项目地址： https://github.com/sripathikrishnan/redis-rdb-tools 安装部署 安装Python2.7 下载redis-rdb-tools git clone https://github.com/sripathikrishnan/redis-rdb-tools.git 安装redis-rdb-tools pip2.7 install python-lzf cd redis-rdb-tools python2.7 setup.py install 常见用法: # 以json格式输出 > rdb --command json /var/redis/6379/dump.rdb # 以json格式输出，模糊查找 > rdb --command justkeyvals --key "user.*" /var/redis/6379/dump.rdb user003 fname Ron,sname Bumquist, user001 fname Raoul,sname Duke, user002 fname Gonzo,sname Dr, user_list user003,user002,user001 # 查找确定键信息 > redis

一、基础结构 redis字符串：扩容，在1M内扩容都是加倍，超过就是1M，最大长度512M 整数的范围：signed long 的最大最小值，超过了这个值，Redis 会报错 hash:渐进式 rehash 会在 rehash 的同时，保留新旧两个 hash结构，查询时会同时查询两个 hash 结 构，然后在后续的定时任务中以及 hash 操作指令中，循序渐进地将旧 hash 的内容一点点迁移到 新的 hash 结构中 set 结构可以用来存储活动中奖的用户ID，因为有去重功能，可以保证同一个用户不会中奖两次 zset 可以用来存粉丝列表，value 值是粉丝的用户 ID，score 是关注时间。我们可以对粉丝列表按 关注时间进行排序 容器型数据结构,如果容器里元素没有了，那么立即删除元素，释放内存 二、架构 哨兵模式 启动哨兵：Sentinel端口：26379，返回主从redis地址，监控主从节点是否正常，客观，主观下线节点 辅助 codis：redis集群中间件 中间代理：将key做hash运算，划分1024个槽位 缺点：不支持事务，rename无法正确操作 集群模式Cluster 相对于 Codis 的不同，它是去中心化的，如图所示，该集群有三个 Redis 节点组成，每个节点负 责整个集群的一部分数据，每个节点负责的数据多少可能不一样。这三个节点相互连接组成一个对 等的集群

【原创】我还是很建议你用DelayQueue搞定超时订单的(1) 我就是那个人见人爱的 锦成同学，我是java进阶架构师社区的特邀作者, 今天为大家带来新的一篇小知识,祝各位宝宝能学到新知识...更上一层楼..... 一、用三根鸡毛做引言 真的! 不骗你们的喔~ 相信大家都遇到类似于:订单30min后未支付自动取消的开发任务 那么今日份就来了解一下怎么用延时队列 DelayQueue搞定单机版的超时订单 二、延时队列使用场景 那么什么时候需要用延时队列呢？常见的延时任务场景 举栗子： 订单在30分钟之内未支付则自动取消。 重试机制实现,把调用失败的接口放入一个固定延时的队列,到期后再重试。 新创建的店铺，如果在十天内都没有上传过商品，则自动发送消息提醒。 用户发起退款，如果三天内没有得到处理则通知相关运营人员。 预定会议后，需要在预定的时间点前十分钟通知各个与会人员参加会议。 关闭空闲连接，服务器中，有很多客户端的连接，空闲一段时间之后需要关闭之。 清理过期数据业务。比如缓存中的对象，超过了空闲时间，需要从缓存中移出。 多考生考试,到期全部考生必须交卷,要求时间非常准确的场景。 三、解决办法多如鸡毛 定期轮询（数据库等） JDK DelayQueue JDK Timer ScheduledExecutorService 周期性线程池 时间轮(kafka) 时间轮

前言 我在程序员这个圈子里包括身边的程序员朋友里经常听到一句话，那就是“程序员这个职业都是吃青春饭的”，为什么这句话在网络上这么多人流传呢，我大概归纳了一下。 大概分为三点：首先这个行业毕业到30岁也工作了几年，如果不是非常热爱的，很多人会产生厌倦心理，从而转业，改行。其次就是这个行业普遍加班很多，工作强度大，很多年纪轻轻的小伙子短短几年就熬成了大叔，而且因为这个行业交流不多，导致很多该行业的人不太会沟通交流，随之的就是只能看着别人过七夕了，在这心疼这些人10秒钟。最后一点，也是最重要的一点，其实有很多人在公司里就是混日子的，不想上进，不想学习，俗称“我们只是代码的搬运工”。 为什么说是最重要的一点呢，因为这个行业的技术发展非常迅速，如果你不思进取，只想着混日子，那就只能等着被淘汰了，我觉得不单单是这个行业，很多行业都是学无止境的，持续提升自己，才能得到更好的！ 经我的一位铁哥们透露，这份字节跳动内部限定的“redis深度历险笔记”，有着非常齐全的知识点和非常强大的核心原理和应用实践。 文章中会主要介绍一下其中重要的知识点和BAT常问的redis面试题，由于文章的限制，不能完全展示给大家，有需要这份“Redis深度历险笔记+BAT常问的面试题”的朋友们， 点击这里 即可快速领取！ Redis深度历险笔记 Redis是用来干什么的 我们要学习Redis

持久化：就是把内存中的数据保存到磁盘 1.Redis为什么要有持久化？ 由于Redis是一个基于内存的数据库，因此数据容易丢失，为了解决数据丢失的问题，于是Redis就设计了持久化 2.Redis的持久的方式有哪些？ 有两个，分别是rdb和aof的持久化方式 3.分别介绍一下Redis的持久化方式的机制 rdb持久化：Redis为我们提供了一个rdb的持久化方式具体每隔一定时间，或者当key的改变达到一定的数量的时候，就会自动往磁盘保存一次 1 save 900 1（900秒后1个key改变） 2 save 300 10（300秒后19个key改变） 3 save 60 10000（60秒后10000个key改变）（save是或者的关系） aof持久化：Redis还为我们提供了一个aof的持久化方式，这种方式是通过记录用户的操作过程（用户每执行一次命令，就会被Redis记录在XXX.aof文件里，如果突然断电了，Redis的数据就会通过重新读取并执行XXX.aof里的命令记录来恢复数据）来恢复数据 4.两种Redis持久化方式的优缺点 都是为了防止数据丢失 rdb:假如三种方式没有一种被满足，触发不了保存，突然断电，那就会丢失数据 aof:为了解决rdb的弊端，就有了aof的持久化，始终在一个文件里保存记录，但aof的持久化随着时间的推移数据量会越来越大，占用很大的空间 来源：

环境：SpringBoot2.x maven增加配置 <!-- redis--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <!--springboot2.0的redis整合包多出lettuce连接池，需要增加commons-pool2包 1.5的版本默认采用的连接池技术是jedis 2.0以上版本默认连接池是lettuce spring boot 2.0 的操作手册有标注 大家可以去看看 地址是：https://docs.spring.io/spring-boot/docs/2.0.3.RELEASE/reference/htmlsingle--> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-pool2</artifactId> <version>2.4.2</version> </dependency> <dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId>