congge

RedisJson使用详解

Redis 高频数据类型使用详解

springboot整合redis哨兵集群使用详解

redis-shake 同步redis数据

redis 分片集群搭建与使用

前言在生产环境下，往往要求系统具备高可用，承载高并发以及有着较好的抵御单点故障的能力，通常来说，使用集群部署可以达到这个目的同样，对于redis的使用，即便单节点的性能已经很高了，但考虑到种种可能造成单点故障以及影响其高并发环境下整体性能的因素，因此，在系统设计之初，最好能结合自身的业务对redis的部署架构做一个整体的评估。是否使用集群关于这个问题，很多同学有不同的见解，比如说项目本身体量不大，在可遇见的业务增长范围内，为了满足快速迭代、快速上线的要求，单节点不是不可以，部署redis单节点，不管

前言

前言在web应用开发中，redis越来越多的应用于各种需要缓存的场景中，比较经典的使用场景就是，使用redis配合mysql做二级缓存，以应对在流量高峰的时候，减少高并发请求对数据库的压力但是在这种简单的架构模式下，如果使用不慎，或者对某些问题没有做到提前的预判，在高并发或者某些特殊场景下，可能会出现缓存穿透，缓存击穿或雪崩的现象缓存穿透请求查询时，key对应的数据在数据源中不存在，从而每次请求的key从缓存中获取不到，请求都会直接打到数据库，当这种请求的量特别大的时候，可能会压垮数据源举例来说

前言在上一篇，通过实例演示了在高并发场景下多人抢购优惠券的超卖问题，并且利用redis+lua解决了超卖问题，但是一人只能抢一单的问题是否还在呢？一人抢多单压测可以发现，在经过改造时候，虽然解决了超卖问题，但是一人可以抢购多单的问题仍然存在为什么会存在这个问题呢？简单分析下面这段代码，扣减库存和下单操作分割为2步，在多线程并发抢购时，第二步判断用户是否抢过和下面的第三步，第四步都是隔开的，假设多个线程都走到第二步，这时候发现当前1111这个用户还没有抢过，继续走到第二步时候，当库存不为0时，

前言在很多社交类APP中，签到功能似乎成了标配，签到功能一方面可以促进APP中用户的活跃度，而且可以绑定一些促销活动刺激用户消费等关联功能设计实现与分析但从此功能的实现上来说，似乎并不是太难，我们完全可以通过创建一个如下简单的表实现和上一篇一样的思路，设想你的APP的用户量是像QQ或微信那种量级的，每天签到的人数加起来该有多少？你的这张表够不够承载一年365天这么庞大用户体量的数据就算可以借助mysql的索引功能加速查询，但是总有一天，该表所在的服务器会有撑不住的一天，而使用那些分库分表之类的

前言在上一篇，讨论了积分排行榜基于mysql的实现方案，并且在文章的末尾我们抛出了一个问题，就是当用户量越来越大的时候，性能的问题将会成为此功能的瓶颈，因此需要寻找更好的解决方案在Redis中，提供了一个叫做SortedSet的数据结构，该数据结构有2个特性，有序性和数据的可压缩性，利用这2个特点，结合上篇分析到的积分排行的业务场景，下面来尝试下如何利用Redis的这种数据结构来实现topN的积分排行榜吧实现思路用户签到插入积分时，同时插入到zset中获取topN的排行信息时候，直接从zset中

前言越来越多的社交类APP为了提升应用的用户活跃度，刺激用户消费，采取签到功能，通过签到进行一系列的促销活动，比如签到赠送积分，通过积分可以兑换相应的礼品，购物抵扣券之类的在某些APP上，有一种积分排行榜的功能，或者游戏APP应用上面也有类似的得分排行榜，这个排行榜一定程度上对玩家来说，如果能上榜，也是不错的成就感以签到送积分为例简单分析下，当前账号绑定的信息，每天签到一次，就往一张签到表中插入一条数据，同时在积分表增加一条数据，最终根据业务需要，展示排行前10或者20的积分用户关于签到 -&gt

前言在上一篇，我们通过一个简单的案例，分享了怎么利用redis设计并实现一个秒杀抢购的功能，关于秒杀功能中，需要注意的比较关键的有两个问题高并发场景下，怎么确保不会超卖高并发场景下，如何确保一人一单具体在设计的时候，需要结合实际的项目和业务场景，比如1000个人抢购50件商品的时候，抢购是一方面，抢购完毕之后还要下单，这个下单的业务是和抢购放在一起呢还是单独处理，需结合具体场景以及系统的架构进行分析下面用一个更通俗的业务场景来比较全面的业务场景描述某些商家为了吸引客户进店消费，推出线上发放

前言抢购问题不仅是电商类项目中一个重要的业务，也是许多开发人员在进阶过程中绕不开的问题，关于抢购，如果理清了前后的逻辑和里面涉及到的几个关键性的问题，问题就迎刃而解了抢购中的几个常见问题如何设计抢购功能？（表结构，以及整体的抢购思路）不借助中间件如何实现抢购？（不借助redis）怎么利用redis解决抢购中的超卖问题怎么提升抢购的整体并发？上图是抢购中的两个重要步骤，对于抢购用户，抽象来讲，服务端只需要完成对待抢购商品的锁定以及锁定后的下单操作即可分开来说，商品名额锁定阶段，活动期间待

前言一般来说，查询成为很多应用对外的性能瓶颈，其主要原因在于一旦并发量上来了，应用后台和数据库或者其他的存储服务的IO交互次数增多了，而服务器的线程资源开销是有限的，如何减少IO次数，这是优化要考虑的一个重要问题使用redis也是如此，试想某些功能的数据使用了缓存，大量的并发请求过来时，是否可以考虑将同类型的数据查询一次性的提交给redis得到查询结果而不是逐个通过get(key)的方式获取更好呢？下面介绍两种在java中优化查询的方式1、使用multiget批量查询多个key新增工具类@Com

前言在上一篇中，我们简单探讨了list的结构和基本使用，了解数据结构的同学对链表的操作应该不陌生，链表的遍历平均时间复杂度为o(n)，这就是说，在redis的list结构中，当集合中的数据量比较大的时候，遍历时性能可能会成为瓶颈，因此，是否有更高效的数据结构可以使用呢？redis中还有一种数据类型，那就是set，set底层基于hash表存储，并且数据不重复，相比list，在数据的遍历上，hash的结构更高效Set简介Set 是 String 类型的无序集合，且集合成员唯一，这就意味着集合中不能出现

前言在上一篇，我们简单介绍了redis数据类型中的String和hash两种常用数据类型的使用，本篇继续探讨redis数据结构中的另一种，list 列表list简介Redis列表是简单的字符串列表，可以按照插入顺序排序。list存储多个数据，对进入list存储结构区域的数据通过先后顺序进行区分底层采用类似双向链表的结构实现一个列表最多可以包含 232 - 1 个元素 (4294967295, 每个列表超过40亿个元素)基本操作操作list时，既然说到底层是双向链表结构，就存在一个左和右的

前言redis在互联网公司的项目中基本上都会使用到，这得益于redis丰富的数据结构和高效的底层存储结构，接下来会通过几篇文章探讨并总结一些redis在实际项目中的使用环境准备window或者linux下，安装一个redis服务，linux下可以参考网上的安装教程，windows下直接官网下载后，双击bin目录下的redis.bat即可运行同时为方便java中使用redis的操作与学习，使用springboot快速搭建一个工程，以便对比需要导入的基本依赖， <dependencies&

前言在上一篇中，我们利用mysql数据库的行锁特性，实现了一个简单的分布式锁，但是从经验即可判断，数据库的分布式锁实现，在高并发场景下性能方面应该会大打折扣，当然，如果能够提前预判系统的并发并不算太大，这种实现也是没问题的，下面介绍下分布式锁的第二种实现，基于redis实现分布式锁redis分布式锁原理redis实现分布式锁的原理其实非常简单，即通过一个 Setnx的命令进行实现，即：SET resource_key_name resource_key_value NX PX 10000简单解释

前言之前在限流的基本解决方案中我们提到了在分布式环境下，可以使用redis搭配lua进行限流，和网关层不同的是，基于Redis+Lua的分布式限流属于服务端的限流为什么使用redis做限流呢？性能前面的章节中大家已经系统学习了Redis，作为缓存组件，如果不采用持久化方案的话，Redis的大部分操作都是纯内存操作，性能十分优异线程安全只用单线程承接网络请求（其他模块仍然多线程），天然具有线程安全的特性，而且对原子性操作的支持非常到位高并发限流服务不仅需要承接超高QPS，还需要保证

之前简单演示过redis的集群搭建和启动，下面简单说说在linux环境下redis单机安装，并且可以通过编写脚本以服务的形式操作redis，1、redis安装，下载安装包，我这里提前下载好了，大家可以上官网进行下载或者通过wget的形式下载，解压后并重新命名一下，tar -zxvf redis-4.0.11.tar.gzmv redis-4.0.11.tar.gz redis42...

1、为什么要使用分布式锁在分布式场景下为了保证数据最终一致性。在单进程的系统中，存在多个线程可以同时改变某个变量（可变共享变量）时，就需要对变量或代码块做同步(lock—synchronized)，使其在修改这种变量时能够线性执行消除并发修改变量。但分布式系统是多部署、多进程的，开发语言提供的并发处理API在此场景下就无能为力了。2.分布式锁的使用场景电商网站用下单操作时需要使用，秒杀活动更...

生产环境下，为保证redis的高可用性，通常会搭建集群，redis集群的好处无需多说，提升单节点的读写性能从而整体提升并发效率，达到整体QPS的提升，同时，多个节点可以实现数据共享，在集群模式下，从节点会通过RDB不断复制主节点数据达到数据的准实时备份，从而保障数据的安全性；既然是redis集群嘛，我们很容易联想到使用一台主节点，多个从节点，实际中也是这样操作的，上一节我们模拟了在同一台机器下实...

如今，redis在各类业务场景中发挥的作用越来越大，其中很重要的一个原因就是redis直接操作的是内存，相比SSD或其他的磁盘等，尤其是在并发量大的读场景下，其性能绝对高出一大截，另一个作为人们选择redis的原因就是其数据可持久化管理，一方面，在实际业务场景中，持久化数据在一段时间内可以大大降低后端应用和数据库压力，另一方面，可以设置过期策略的方式为其自身内存的管理提供了较好的伸缩性，但同时，作...

我们知道，在实际的生产环境中，为了高可用，一般涉及到数据的服务器都会做主从，redis作为数据存储的服务器，在实际生产中，同样需要做主备，当然，条件允许的情况下，还可以做多个节点，形成集群，每个节点再分别做主备，这样就更加可靠，根据各公司实际情况而定，下面将演示如何搭建redis主从备份，3节点或更多的节点原理基本类似，大家稍后可在此基础上进行拓展；资源准备，centos6.5 , redis-...

之前的项目中，用到过redis，主要是使用redis做缓存，redis在web开发中使用的场景很多，其中缓存是其中一个很重要的使用场景，之所以用作缓存，得益于redis的读写数据，尤其是在读取数据的时候是直接走内存的，这样在高并发访问数据的时候，和查询数据库相比，redis读取数据的高效性、快速性的优势可见一斑，据说新浪单是每天的所有内容的统计的总的访问数量可以达到上百亿次，这种场景下，如果没有r...