Redis

今天我们来聊聊缓存这个话题，看看在微服务环境下如何设计有效的多级缓存架构。主要涉及三方面内容： Web 应用的客户端缓存； 应用层静态资源缓存； 服务层多级缓存

日常开发中，经常会碰到秒杀抢购等业务。为了避免并发请求造成的库存超卖等问题，我们一般会用到Redis分布式锁。但是使用Redis分布式锁，很容易踩坑

需求是做一个秒杀系统，比如大家来抢100台手机，先到先得。 查阅了网上很多用redis实现秒杀的demo（java语言），竟然没一个能用的

在一个分布式系统中，由于涉及到多个实例同时对同一个资源加锁的问题，像传统的synchronized、ReentrantLock等单进程情况加锁的api就不再适用，需要使用分布式锁来保证安全性

分布式缓存作为性能加速器，在系统优化中承担着非常重要的角色。相比本地缓存，虽然增加了一次网络传输，大约占用不到 1 毫秒外，但是却有集中化管理的优势，并支持非常大的存储容量

我们都知道Redis是微服务架构中重要的基础数据库中间件，通过Redis可以将数据库中的数据缓存到内存中，当服务端有数据查询请求的时候，可以直接从内存中获取数据

Java缓存技术可分为远端缓存和本地缓存，远端缓存常用的方案有著名的redis和memcache，而本地缓存的代表技术主要有HashMap，Guava Cache，Caffeine和Encahche。

今天下午和一位同学聊Redis集群，这玩意真没那么简单，内容非常多，满满都是干货，收藏起来慢慢研究，你会发现收获不少，够喝一壶了

在分布式系统中，由于redis分布式锁相对于更简单和高效，成为了分布式锁的首先，被我们用到了很多实际业务场景当中。 但不是说用了redis分布式锁，就可以高枕无忧了

数据库和缓存（比如：redis）双写数据一致性问题，是一个跟开发语言无关的公共问题。尤其在高并发的场景下，这个问题变得更加严重。 我很负责的告诉大家，该问题无论在面试，还是工作中遇到的概率非常大

Redis 分布式锁使用 SET 指令就可以实现了么？在分布式领域 CAP 理论一直存在。 分布式锁的门道可没那么简单，我们在网上看到的分布式锁方案可能是有问题的。 一步步带你深入分布式锁

在高性能的服务架构设计中，缓存是一个不可或缺的环节。在实际的项目中，我们通常会将一些热点数据存储到Redis或MemCache这类缓存中间件中，只有当缓存的访问没有命中时再查询数据库

最近项目的生产环境遇到一个奇怪的问题： 现象：每天早上客服人员在后台创建客服事件时，都会创建失败。当我们重启这个微服务后，后台就可以正常创建了客服事件了。到第二天早上又会创建失败，又得重启

有些业务请求，属于耗时操作，需要加锁，防止后续的并发操作，同时对数据库的数据进行操作，需要避免对之前的业务造成影响。

业务场景中经常会有各种大key多key的情况， 1：单个简单的key存储的value很大 2：hash， set，zset，list 中存储过多的元素（以万为单位） 3：一个集群存储了上亿的key

后端程序员，不管是出去面试，还是当面试官，Redis几乎是100%会问到的技术点；究其原因，主要是因为他实在过于强大、使用率太高了；导致项目中几乎无处不在。 那Redis部分，不出意外，第一个问题就是

今天跟大家聊聊，ZSet 对象的底层数据结构实现之一是跳表。 然后，有读者就问：为什么不使用平衡树（如红黑树、AVL 树）？ 我们先来了解下跳表，再来回答这个问题

Redis（REmote DIctionary Service）是一个开源的键值对数据库服务器。 Redis 更准确的描述是一个数据结构服务器。

日常开发中，秒杀下单、抢红包等等业务场景，都需要用到分布式锁。而Redis非常适合作为分布式锁使用。