一.前言
随着互联网的普及，大多互联网项目面对着高并发的挑战，而传统的关系型数据面对着这种高并发的挑战已经远远达不到这种访问要求了，哪怕是做了数据库集群，但总有瓶颈所在，所以我们不能直接把所有的压力直接放到传统的关系型数据库上，这时候我们就需要引入缓存，因为大多数的访问都需要访问数据，而一部分不是实时性要求很高但又有很大的访问需求的数据我们可以选择抽离出来，用性能更高的载体来面对高并发的压力。
二.NoSQL
NoSQL泛指各种非关系形数据库，比如Redis，Memcached，MongoDb等林林总总超过十几种，这个可以根据业务需要结合各种非关系形数据库的特点进行选型，而我们选用了Redis。 首先来简单说说Redis的特点，Redis的存储是基于内存形式以键值对形式存储的数据库，因为是基于缓内存存储的形式，读写速度非常优越，但切记不要存储大容量的数据！当然它也支持持久化，与之相似的Memcache也是这样的形式，但不支持持久化，通信协议也不一样（这个主题是不是关于技术选型的就不赘述差异了）。Redis提供五种数据结构的存储方式 ：hash，string,list,set,sortset。可以根据业务需求进行选择使用哪种数据结构。
三.搭建思路
1.首先需要进行数据归类，我们把实时性要求较低但访问需求大的数据分类出来，如用户账号，手机号等，然后在用户第一次访问自身用户数据的时候注入进去，后续接口则通过读取该缓存进行查询；
2.用户第一次访问数据的时候一般是用户登录的时候，这个是个很好的缓存注入时机，因为用户登录一般是最早访问自身数据的，而且单个用户登录一般是单次进行的，这样可以避免在后续调用缓存时缓存穿透；
3.存储方式我个人推荐Redis的hash结构，因为用户相关的东西很多，用户的个人信息只是一部分，而Redis又有个关系结构性差的特点，在进行数据管理的时候，hash可以包含多个集合，可以更好地进行数据管理和查询；
4.查询可以在接口鉴权的时候查询出来，然后传到业务里面使用。但不推荐数据和token直接绑定，虽然鉴权的时候保证了数据是存在的，但某些业务查询是没有直接通过接口的，所以这样可能会导致查询失败或者缓存穿透，因此这里推荐使用用户特征来绑定缓存，比如用户的账户ID，保证缓存具有永久的时效性，鉴权时，通过Token绑定用户ID，再通过用户ID去查询用户缓存，或者若没办法通过接口来获取的缓存的业务，我们也同意通过用户特征来查询。
