redis支持的数据类型-hash
key为字符串，值分为两部分field和value，视为属性和值。
可以把key当作一张表的一行，Key就代表一个id，每个属性可以看作关系型数据库的一个字段。fields不能相同，value可以。
哈希键值结构，由key(String类型） field（属性） value（值）三部分组成，一个key可以对应多个 field-value，可以把它看成一个对象。
哈希命令是以字母h为前缀：
hget key field | 获取hash key对应的field的value |
hset key field value | 设置hash key对应field的value |
hdel key field | 删除hash key对应field的value |
hexists key field | 判断hash key是否有field |
hgetall key | 返回所有field。小心该命令，很多key的情况下可能造成阻塞 |
hlen key | 获取hash key field的数量 |
hmget key field1 field2… field n | 批量获取hash key的一批值 |
hmset set f1 v1 f2 v2… | 批量设置值 |
hvals key | 返回hash key对应所有field的value |
hkeys key | 返回hash key对应所有field |
hsetnx key field value | 设置Hash key对应的field的value（如果field存在，则失效） |
hincrby key field intCounter value | 自增intCounter |
hincrbyfloat | 自增小数 |
应用场景：在Memcached中，我们经常将一些结构化的信息打包成HashMap，在客户端序列化后存储为一个字符串的值，比如用户的昵称、年龄、性别、积分等，这时候在需要修改其中某一项时，通常需要将所有值取出反序列化后，修改某一项的值，再序列化存储回去。这样不仅增大了开销，也不适用于一些可能并发操作的场合（比如两个并发的操作都需要修改积分）。而Redis的Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值。
我们简单举个实例来描述下Hash的应用场景，比如我们要存储一个用户信息对象数据，包含以下信息：
用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储，主要有以下2种存储方式：
第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储，这种方式的缺点是，增加了序列化/反序列化的开销，并且在需要修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护，引入CAS等复杂问题。
第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿，用用户ID+对应属性的名称作为唯一标识来取得对应属性的值，虽然省去了序列化开销和并发问题，但是用户ID为重复存储，如果存在大量这样的数据，内存浪费还是非常可观的。
那么Redis提供的Hash很好的解决了这个问题，Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口，如下图：
也就是说，Key仍然是用户ID, value是一个Map，这个Map的key是成员的属性名，value是属性值，这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。很好的解决了问题。
这里同时需要注意，Redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部Map的成员很多，那么涉及到遍历整个内部Map的操作，由于Redis单线程模型的缘故，这个遍历操作可能会比较耗时，而另其它客户端的请求完全不响应，这点需要格外注意。
