Ulrich蚊子Blog

目前市场上许多软件产品，其内部都采用 Redis 作为数据缓存的主要解决方案。随着业务的不断发展，在高并发场景里，Redis 常常会出现一些问题，网络上也有很多文章对其做出了总结。这里主要针对这几类场景进行分析，并提出可能的处理方案。需要强调的是，以下的分析仅供参考，具体决策和实现效果必须要结合具体的业务场景，实事求是地进行应用。

概述布隆过滤器（Bloom Filter）是布隆在1970年提出的，它可以用来检索一个元素是否在一个集合中。实际上布隆过滤器通过一个二进制向量和一系列随机哈希函数完成元素检索，其优点在于比一般的算法具有更高的时间效率和空间效率，但其缺点是有一定的误差以及难以进行删除操作。原理布隆过滤器的核心就是哈希函数，可以将其看作是对 bitmap 的拓展，通过将添加的元素经过 k 个哈希函数映射到一个很长的 bit 向量中的 k 个位置，并将它们置为 1。检索时，通过判断这个位置是否都为 1 就能大概知道集合中是

简介Redis 全称为 Remote DIctionary Server，本质上是一个 key-value 存储系统，属于跨平台的非关系型数据库。Redis 官方对它的定义是：Redis is an open source (BSD licensed), in-memory data structure store, used database, cache and message broker.翻译成中文就是：Redis 是一个开源的（BSD 许可），基于内存的数据结构存储系统，可用作数据库、缓

业务场景问题：假设我们现在有一个网站，需要记录每天的 UV 数据，那应该采取什么方案来实现呢？如果只是统计网站的 PV，那么给每个网页配置一个独立的 Redis Key 即可，key 中可以加上日期信息实现历史数据的记录。这样每当有一个用户访问当前网站，就对应执行一次 incrby。但是 UV 不同，它需要实现去重的操作，说到去重，大家第一时间想起的可能就是 set 或者 hashmap 这样的数据结构。但是如果网站的流量达到千万级别甚至上亿，那么它们就会十分消耗内存了。因此，我们还可以考虑使用 red

Redis 基础数据结构Redis 提供了 5 种基础的数据结构，它们分别是：String，Hash，List，Set，Sorted Set。Redis 缓存数据是以 key - value 的形式进行存储的，key 是一个唯一的字符串，通过操作唯一的 key 值来获取相应的 value 数据。不同数据结构的数据，也就决定了 value 的结构不一样。String（字符串）Redis 的 String 是一个动态的字符串，可以被修改，其内部结构实现是一个字符数组，类似于 Java 的 ArrayLis

前言在业务环境中，频繁访问数据库获取数据的做法是不可取的，为了提升数据请求的效率，目前比较流行的做法就是使用 Redis 缓存服务，将频繁被请求的数据缓存起来，在下一次数据被请求时，根据设定的 key 返回相应的数据。但是，缓存系统的存在，就导致数据库和 Redis 之间需要我们考虑其数据同步的问题。由于两者的数据更新必然不是同时进行的，因此当其中一方出现数据更新时，正在进行的访问就有可能从另一方获取到“肮脏”的数据。接下来，我们就分析一下可能存在的几种方案以及他们各自的优缺点。方案一：懒加载服务运行

在现实中很多的业务场景里，人们常常使用 Redis 作为缓存使用。其性能高，支持数据结构丰富，还具备多种优势特性。在日常业务中，通常的请求处理过程为：业务系统有请求进来，先查缓存，查不到数据再去查 DB 层，命中后回写缓存，再返回数据。这种模式称之为“赖加载”模式。这样使用缓存策略一般也不会遇到问题，但是当业务平台越来越大，用户数量越来越大的时候。平台要开始考虑高并发场景下是否系统是否支撑的下去。尤其是考虑瞬间大量请求时，系统如何设计。存在读写压力，可以采用数据库分库分表的方式，不过基于成本考虑，数据