string

可以简单任务Redis的String结构是用SDS（简单动态字符串）数据结构来实现的。

• len：buf中已占用空间的长度；
• free：buf中剩余可用空间的长度；
• buf[]：数据空间

hash结构使用ziplist结构时：

• zlbytes：32bit，表示ziplist占用的字节总数。
• zltail：32bit，表示ziplist表中最后一项（entry）在ziplist中的偏移字节数。通过zltail我们可以很方便地找到最后一项，从而可以在ziplist尾端快速地执行push或pop操作，保证了时间复杂度为O(1)
• zlen：16bit， 表示ziplist中数据项（entry）的个数。
• entry：表示真正存放数据的数据项，长度不定。
• zlend： ziplist最后1个字节，是一个结束标记，值固定等于255。

ziplist最大的特点就是，他不是hashtable结构，而是一个比较长的字符串，将key-value都按照顺序依次摆放到一个长长的字符串里来存储。如果要找某个key，就需要遍历整个长字符串。

原因：使用string存储数据时，每一个记录都是一个SDS都需要存在len、free来标识。但是使用hash的ziplist时，只需要标头的几个标识位外，接着都是紧凑的数据。这就是为什么hash(ziplist)比string更节省内存的原因。

Redis如何存储hash

2.1 hash的两种结构

hash数据结构，在编码方式上有两种，1是hashTable，2是zipList。

• hashTable和Java的HashMap很像，都是数组+链表的实现方式。Java中HashMap为了减少hash冲突，设置了负载因子为0.75，同理redis的Hash也有类似的扩容负载因子。这就意味着使用hashTable编码的话，会花费至少大于存储数据的25%的空间才能存下这些数据。
• zipList它不是hash结构，而是一个比较长的字符串，将key-value都按顺序依次摆放到一个长长的字符串里来存储。如果要查找某个key，就直接遍历整个长字符串就好了。

换句话说，zipList比起hashTable占用的空间少，但是会耗费更多cpu来进行查询。

2.2 hash两种结构的使用时机

1. 当hash结构的内层field-value数量不超过512（hash-max-ziplist-entries）。
2. 并且value字节数不超过64（hash-max-ziplist-value）时，就使用zipList。

经过实测，value数量在512时，性能和单纯的hashTable几乎无差别，在value数量不超过1024时，性能仅有极小的降低，可以忽略。

而内存占用，zipList比hashTable降低极多。

使用hash存储对象

优点：

1. 结构化存储：Hash允许你将一个对象的多个字段和值组织在一个数据结构中，这些字段和值可以具有不同的数据类型（例如字符串、整数等）。这对于存储复杂的数据对象非常有用，因为你可以轻松地添加、删除或更新字段。
   
   
2. 易于扩展：如果对象的字段需要变化，你可以直接在Hash中添加或删除字段，而不必重新设计整个数据模型。这使得Hash适用于数据模型的演化。
   
   
3. 少占用内存：相对于每个字段都存储为单独的String，使用Hash可以节省内存，因为Hash的开销相对较小。
   
   

缺点：

1. 不适合小对象：如果你的对象非常小，只包含少量字段，使用Hash可能会浪费一些内存和存储空间。
   
   
2. 难以进行全文搜索：如果需要在对象的文本字段上执行全文搜索操作，使用Hash可能不是最佳选择，因为Hash中的字段不容易进行全文搜索。