redis有哪些数据类型,redis有哪些数据类型？

Redis中的所有 value 都是以 Object 的形式存在的，其通用结构如下：

typedef struct redisObject {

unsigned [type] 4;

unsigned [encoding] 4;

unsigned [lru] REDIS_LRU_BITS;

int refcount;

void *ptr;

} robj;

• type：指类型，String、Hash、List、Set、ZSet；
• encoding：类型具体的实现方式；比如 Set 是用 hashTable 实现还是 intSet 实现；
• lru：最后一次被访问的信息，其实一看到 LRU 估计也就和淘汰策略有关；
• refcount：对象引用计数；
• ptr：指向实际实现者的地址；

String

Redis 中的 String 不仅仅表示 字符串，还可以表示 整型、浮点型。

String 的编码可以是 int、raw 或者 embstr；单说普通的字符串，就有 raw 和 embstr 两种实现方式，embstr 是 Redis 3.0 新增的数据结构：

字符串长度小于 39 字节，就用 embstr 对象，否则用传统的raw对象（Redis 3.2版本之后，这里变成了以 44 字节为分界）。

embstr 的优势在于创建时少分配一次空间（RedisObject 和 sds 是连续的），删除时少释放一次空间，以及对象的所有数据连在一起，寻找方便；

当然缺点也非常明显，如果字符串的长度增加，需要重新分配内存的时候，整个 RedisObject 和 sds 都需要重新分配空间。

修改 embstr 对象的时候，Redis 会将其转换成 raw 格式再进行修改，所以 embstr 对象修改之后的对象，一定是 raw 的。

应用场景：常规计数都可以使用，可用作缓存、计数、限速等等，比如商品剩余数量，字典表信息，长度不能超过 512MB。

Hash

Hash 对象的底层实现可以是 ziplist 或者 hashtable。

ziplist：在这个数据结构中，是按照 key1, value1, key2, value2 这样的顺序存放来存储的；

hashTable：是由 dict 这个结构来实现的。（这个结构比较复杂，后面单写一篇来说）

应用场景：Hash 适用于存储结构化的对象，可以直接修改这个对象中的某个字段的值；比如用户信息。

List

List 对象的编码可以是 ziplist 或者 linkedlist，从名字上也能看出来两种结构都是啥。

ziplist：是一种压缩链表，它存储数据都是连续地放在内存区域当中。

linkedlist：是一种双向链表。

应用场景：通常网站上的消息列表，可以使用 List 来进行存储；另外 lrange 命令，从某个元素开始，读取多少个元素，可以看做是分页查询，比如很多网站上那种不断下拉，不断分页的效果。

Set

Set 相对于 List 来说，Set 是可以自动排重的；它的编码可以是 intset 或者 hashtable 。

intset：是一个整数集合，支持三种长度的整数：int16_t、int32_t、int64_t；集合中的数据长度必须是一致的，比如一个 int16_t 长度的 Set，当插入了一条 int32_t 长度的数据，那么所有的数据都会转成 int32_t 长度（不支持降级）。

hashTable：对于 Set 来说，hashTable 的 value 永远为 NULL。

应用场景：如果要存储一个列表，同时又需要做数据排重的时候，可以使用 set ；另外，Redis 还为 Set 提供了求交集、并集、差集等操作，比如微博上面的【共同关注】这个功能，就可以用 Set 实现。

ZSet / Sorted Set

和 Set 相比，ZSet 增加了一个参数 score，集合中的元素按照 score 进行有序排列。

有序集合的编码可能两种，一种是 ziplist，另一种是 skipList 与 hashTable 的结合。

ziplist：和 Hash 类似，元素 和 score 都是按顺序存放的；比较适合用于元素内容不大的场景。

skipList + hashTable：是一种添加，移除，更新元素等操作更高效的数据结构，这个跳跃表的数据结构，我近期会发一篇文章单独介绍。

应用场景：有序 + 排重的场景，比如经常玩游戏的同学，应该不会陌生各种排行榜，就可以使用 ZSet 来实现。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注；关注我后，可私信发送数字【1】，获取学习资料。

如何解决Redis缓存和MySQL数据一致性的问题？

在高并发的业务场景下，数据库的性能瓶颈往往都是用户并发访问过大。所以，一般都使用redis做一个缓冲操作，让请求先访问到redis，而不是直接去访问MySQL等数据库。从而减少网络请求的延迟响应

数据为什么会不一致

这样的问题主要是在并发读写访问的时候，缓存和数据相互交叉执行。

一、单库情况下

同一时刻发生了并发读写请求，例如为A(写) B (读)2个请求

1. A请求发送一个写操作到服务端，第一步会淘汰cache，然后因为各种原因卡主了，不在执行后面业务(例：大量的业务操作、调用其他服务处理消耗了1s）。

2. B请求发送一个读操作，读cache，因为cache淘汰，所以为空

3. B请求继续读DB，读出一个脏数据，并写入cache

4. A请求终于执行完全，在写入数据到DB

   总结：因最后才把写操作数据入DB，并没同步。cache里面一直保持脏数据

   脏数据是指源系统中的数据不在给定的范围内或对于实际业务毫无意义，或是数据格式非法，以及在源系统中存在不规范的编码和含糊的业务逻辑。

二、主从同步，读写分离的情况下，读从库而产生脏数据

1. A请求发送一个写操作到服务端，第一步会淘汰cache

2. A请求写主数据库，写了最新的数据。

3. B请求发送一个读操作，读cache，因为cache淘汰，所以为空

4. B请求继续读DB，读的是从库，此时主从同步还没同步成功。读出脏数据，然后脏数据入cache

5. 最后数据库主从同步完成

   总结：这种情况下请求A和请求B操作时序没问题，是主从同步的时延问题(假设1s)，导致读请求读取从库读到脏数据导致的不一致

根本原因:

单库下，逻辑处理中消耗1s。可能读到旧数据入缓存

主从+读写分离，在1s的主从同步时延中。读到从库的旧数据入缓存

数据优化方案

一、缓存双淘汰法

1. 先淘汰缓存

2. 再写数据库

3. 往消息总线esb发送一个淘汰消息，发送立即返回。写请求的处理时间几乎没有增加，这个方法淘汰了缓存两次。因此被称为“缓存双淘汰法“，而在消息总线下游，有一个异步淘汰缓存的消费者，在拿到淘汰消息在1s后淘汰缓存，这样，即使在一秒内有脏数据入缓存，也能够被淘汰掉。

二、异步淘汰缓存

上述的步骤，都是在业务线里面执行，新增一个线下的读取binlog异步淘汰缓存模块，读取binlog总的数据，然后进行异步淘汰。

1.思路：

MySQL binlog增量发布订阅消费+消息队列+增量数据更新到redis

1）读请求走Redis：热数据基本都在Redis

2）写请求走MySQL: 增删改都操作MySQL

3）更新Redis数据：MySQ的数据操作binlog，来更新到Redis

2.Redis更新

1）数据操作主要分为两块：

• 一个是全量(将全部数据一次写入到redis)

• 一个是增量（实时更新）

这里说的是增量,指的是mysql的update、insert、delate变更数据。

这样一旦MySQL中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至Redis，Redis再根据binlog中的记录，对Redis进行更新。就无需在从业务线去操作缓存内容

如有感悟，欢迎关注和交流探讨额

Redis非关系性数据库有什么特点？

简单地说，Redis是一个高性能的key-value数据库，常用于搭建缓存系统，提高并发响应速度。典型的数据读取流程：

一，支持存储多种数据类型

string(字符串)、list(链表)、set(集合)、zset(sorted set有序集合)和hash（哈希类型）。

二，数据操作

push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。

三，多种语言客户端

提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。

四，支持主从同步

可以集群化部署，数据从主服务器向任意数量的从服务器上同步。

五，集成方便

以Java + Spring Boot为例：