1. hash底层简介
redis中的对象定义如下：
typedef struct redisObject {
unsigned type:4;
unsigned encoding:4;
unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
* LFU data (least significant 8 bits frequency
* and most significant 16 bits access time). */
int refcount;
void *ptr;
} robj;
type:表示对象类型，对象类型可以为以下任意一种：字符串对象、列表对象、哈希对象、集合对象、有序集合对象。这也是redis中5种数据类型。
encoding:记录了对象所使用的编码格式。
lru:记录对象最后一次被命令程序访问的时间。
refcount：共享该对象的数量
ptr：指向底层实现数据结构的指针
hash对象的编码可以使ziplist或者hashtable，具体使用什么编码，取决于hash中保存的键值对。满足以下两个条件的，都是用ziplist编码，其余情况都是用hashtable编码。
- 哈希对象保存的所有键值对的建和值的字符串长度都小于64字节，使用ziplist编码；
- 哈希对象保存的键值对数量小于512个，使用ziplist编码；
使用ziplist编码时，先将新加入的键压进表尾，再将值压进表尾，因此在压缩列表中，一对键和值的内存始终是挨着的。
1.1 ziplist和hashtable简介
1.1.1 压缩列表ziplist简介
ziplist的实现在ziplist.c文件中。
ziplist是redis的数据结构之一，通常ziplist的层次结构如下：
<zlbytes> <zltail> <zllen> <entry> <entry> ... <entry> <zlend>
zlbytes:记录压缩列表的总共占多少字节
zltail:记录ziplist最后一个节点的位置
zllen:记录ziplist中有多少个节点
zlend:记录ziplist的末端
例：
[0f 00 00 00] [0c 00 00 00] [02 00] [00 f3] [02 f6] [ff]
| | | | | |
zlbytes zltail entries "2" "5" end
| | | |
p 12 2 p + 12
p为指向压缩列表的起始指针，zltail的十进制为12，表示p + 12，则为最后一个节点的位置，entries表示该ziplist中有两个节点
entry的结构如下：
<prevlen> <encoding> <entry-data>
prevlen:前一个entry的长度，单位字节
encoding：记录了节点保存数据的类型和长度。
entry-data:负责保存节点的值，可以是一个字节数组或者一个整数。
1.1.2 hashtable简介
redis中字典的底层实现就是hashtable。一个哈希表里可以有多个哈希节点，哈希表的实现在dict.h中，hashtable的结构定义如下：
typedef struct dictht {
dictEntry **table; //hashtable数组
unsigned long size;//哈希表大小
unsigned long sizemask;//hashtable掩码，计算索引值
unsigned long used;//hashtable已有节点数量
} dictht;
table是一个hash数组，其中每个节点dictEntry保存着一个键值对，声明如下：
typedef struct dictEntry {
void *key;
union {
void *val;
uint64_t u64;
int64_t s64;
double d;
} v;
struct dictEntry *next;
} dictEntry;
从这个结构中可以看出，key为键值对中的键，v为键值对中的值，其中值可以是一个指针，uint64_t类型，int64_t类型，也可以是double类型。next指向下一个hash节点。
redis使用的hash函数为murmurhash2算法，该算法的优点是计算速度快，并且即使输入的键是连续的，该算法也能给一个很好的随机分布。
当一个新的键值对添加进字典里，流程如下：
- 通过键计算hash值
hash = dict->type->hashFunction(key)
- 根据计算出的hash值找出索引值
index = hash & sizemask; 这里的sizemask就是dictht中的sizemask。
键冲突问题
肯定会有两个不同的键值对落到相同的索引上，为了速度考虑，程序总是将新的键值加到链表的头位置。例如{k0,v0},{k1,v1}落在同一个索引上，k0先插入，k1再插入的时候，就会在k0前面，k1的节点的next会指向k0的位置。
rehash
hashtable保存的值会不断的增多或者减少，为了让hashtable的负载因此维持在一个合理范围内，当hashtable中节点的数量过多或过少，hashtable的大小会进行扩展或收缩，称之为rehash。
2. hash的基本操作命令
hash的基本命令网上随便一搜就出来了，这里想说的是希望大家更好的利用redis的help命令。
在redis里输入help，就能看到怎么使用.
127.0.0.1:6379> help
redis-cli 6.0.5
To get help about Redis commands type:
"help @<group>" to get a list of commands in <group>
"help <command>" for help on <command>
"help <tab>" to get a list of possible help topics
"quit" to exit
使用help @<group>，就能看到该类型一系列的操作方法，例如输入：help @hash，就能看到针对hash的操作命令
127.0.0.1:6379> help @hash
HDEL key field [field ...]
summary: Delete one or more hash fields
since: 2.0.0
HEXISTS key field
summary: Determine if a hash field exists
since: 2.0.0
HGET key field
summary: Get the value of a hash field
since: 2.0.0
... ...后面一堆命令，可以自己试下
如果不知道某一条命令怎么使用，可以用：help HDEL，就能知道HDEL命令是做什么的。
所以善用redis中的help命令，减少终端和浏览器的切换，效率飞升。
3. hash的使用场景
如果你的对象只有一个key，那么使用string类型即可，大可不必用hash；
如果该对象中有很对属性，例如用户信息，里面包含了用户的uid、昵称、头像等等一系列信息，那么用hash。
一般在大型项目中，用户的某个相关信息可能不止在一个库中，并且这些信息也不经常变化，那么这个时候hash也可以派上用场，查出各个库中的信息后，汇总在一起，放进redis中的hash对象中，这样用户下回进来时，在redis中查速度就会快很多，我们只需要设计一个redis的更新机制即可。
也就是hash更适合存储一些某个key下有多个属性的情况。
参考资料:《Redis设计与实现》
