当数据库中的数据修改时，
无论是先更新数据库、再更新缓存还是先更新缓存、再更新数据库；都可能会在两个更新请求的时候出现并发问题，比如请求A先进行修改数据库中的数据为1，另外一个请求B进行了数据库和缓存中的修改为2，之后请求A再修改缓存中的数据为1，就会导致缓存和数据库数据不一致的情况发生。然后删除缓存是一种懒加载的思想，因为每次更改数据之后，不一定立马就有人来用。 若更新的次数远大于读取的次数，此时会频繁更新缓存，会非常浪费性能资源。
Redis 中比较常见的数据类型有下面这些：
除了上面提到的之外，还有一些其他的比如 Bloom filter（布隆过滤器）、Bitfield（位域）。
String是 Redis 中最简单同时也是最常用的一个数据类型。String的底层数据结构实现是SDS。
虽然 Redis 是用 C 语言写的，但是 Redis 并没有使用 C 的字符串表示，而是自己构建了一种简单动态字符串（Simple Dynamic String，SDS）。相比于 C 的原生字符串，Redis 的 SDS 不光可以保存可以用来存储任何类型的数据而且还是二进制安全的，除此之外SDS API也更安全，不会造成缓冲区溢出。并且获取字符串长度复杂度为 O(1)（C 字符串为 O(N)）,
高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。
假设系统一直能够提供服务，我们说系统的可用性是100%。如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。
那么如何保证系统的高可用呢？
在整个架构的每个节点中，不允许存在『单点问题』，因为单点一定是高可用最大的风险点，我们应该在系统设计过程中去避免单点问题。
在实现方法上，一般采用的就是集群部署、或者冗余部署来实现。这样的设计使得如果某个节点出现故障，其他的节点还可以继续使用。
Redis 的读写操作都是在内存中，所以 Redis 性能才会高。但是当 Redis宕机或者重启后，内存中的数据就会丢失，那Redis 实现了数据持久化的机制，把数据存储到磁盘，这样Redis重启后就能够从磁盘中恢复原有的数据。
Redis 共有三种数据持久化的方式：
缓存穿透说简单点就是大量请求的 key 是不合理的，根本不存在于缓存中，也不存在于数据库中 。这就导致这些请求直接到了数据库上，根本没有经过缓存这一层，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。
举个例子：某个黑客故意制造一些非法的 key 发起大量请求，导致大量请求落到数据库，结果数据库上也没有查到对应的数据。也就是说这些请求最终都落到了数据库上，对数据库造成了巨大的压力。
最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。
