最近遇到一个需求，就是做联盟链做存证上，部分交易对外公开，或者是对指定人可见。之前一直在思考用Mysql怎么存合适，想来想去也没找出个合适的办法。
点赞功能场景和上面的需求是一样的，我就借这个简单一些的点赞功能来理清下思路把。
我们先看点赞功能的需求：
微博这是头部的顶级流量，后端肯定是有复杂架构的，我们今天暂时只讨论大众化的方案。
采用mysql做点赞功能的记录的话，一般是要三个表：
那么点赞功能常用的查询就是：
select user_id from star where post_id=?
select post_id from star where user_id=?
虽然我们这里讨论的是大众化的方案，但不是说的数据量小，只是说的架构简单。
我们思考下，如果使用单表查询，一个表肯定是支撑不住的，即使建立了两个索引数据库表的压力也是很大的。
这时只能考虑分库分表，那么怎么分表成为了一个难题：是按照用户id分还是文章id分呢？因为不用的查询，有时涉及到分表后的单表，有时涉及到多表。这样Hash起来是有冲突的。
那么只能考虑做两个分表的冗余，不过这增加了存储空间和维护工作量，还可能有一致性问题。
所以，使用mysql来做点赞功能，不是很好。
由于点赞这种动作很随意，很多人看到大拇指就想点，所以数据量增长很快，数据规模上来后，对mysql读写都有很大的压力，这时就要考虑redis了。
采用redis有两种用途，一种是storage，一种是cache。
Redis具有丰富的数据类型，支持字符串（strings）、散列（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等。
Redis 内部使用一个 redisObject 对象来表示所有的 key 和 value。type 表示一个 value 对象具体是何种数据类型，encoding 是不同数据类型在 Redis 内部的存储方式。
比如：type=string 表示 value 存储的是一个普通字符串，那么 encoding 可以是 raw 或者 int。
我们可以看到使用点赞列表，最合适的方式还是Hash或者List了。如果需要记录点赞人和被点赞人，还有点赞状态（点赞、取消点赞），还要固定时间间隔取出 Redis 中所有点赞数据，使用Hash能够保存key和value，算是更合适的了。
关于底层编码的实现方案，我以后的文章会做介绍。
场景a ：显示点赞数量
在点赞的地方，只是显示一个点赞数量，能区分用户是否点赞过，一般用户不关心这个列表，这个场景只要一个数字就可以了，当数量比较大时，一般显示为"7k" ,“10W” 这样。
以文章id为key。
//以文章id=888为例
127.0.0.1:6379[2]> set star:tid:888 898 //设置点赞数量
OK
127.0.0.1:6379[2]> incr star:tid:888 //实现数量自增 (integer)
899
场景b：点赞去重，避免重复点赞
要实现这个需求，必须有文章点赞的uid列表，以tid为key。
场景c：一般在用户中心，可以看到用户自己的点赞列表
这个需求和上面的差不多。
场景d：文章的点赞列表
类似场景b，以文章id为key。
//以文章id=888为例
127.0.0.1:6379[2]> sadd star:list:tid:888 123 456 789 //点赞uid列表 (integer)
3
127.0.0.1:6379[2]> sismember star:list:tid:888 456 //判断是否点赞 (integer)
1
redis作为storage使用时，一定要做好数据的持久化，必须开启 rdb 和 aof，这会导致业务只能使用一半的机器内存，所以要做好容量的监控，及时扩容。
基于 SpringCloud, 用户发起点赞、取消点赞后先存入 Redis 中，再每隔两小时从 Redis 读取点赞数据写入数据库中做持久化存储。
这一点，以后有机会再做详细介绍。