就一个项目引发的redis挖矿（未完待续）

项目描述
项目的出发点：2000年以来就业人数激增、但仅用10%的人对自己从事的工作满意、存在千里马常有，伯乐不常有的求职痛点。因此开展人才生态圈项目，搭建一个开放的求职招聘平台。
项目的技术选型：前端使用zui和layui框架，因为这两个框架做出来的界面简洁美观，同时提供了丰富的弹框样式。后端则使用ssm框架 即持久层的mybatis框架，业务层的Spring框架处理事务，以及springMVC处理控制层，前后端交互使用ajax技术。
项目的模块划分呢，前台用户包含技术成长模块，用于用户自我学习，找工作模块用户可实现求职，个人中心模块则可以进行简历填写和求职进度查看。而后台则设有三大角色，高校人员负责推荐人才，企业人员负责筛选人才，系统管理员负责对企业高校进行资质审核。
核心功能的设计思路：企业人员在登录系统后可以进行岗位发布，前台用户在填写好简历就可以进行岗位投递，面试后，一经录用则完成找工作，否则就继续进行岗位投递，而企业人员在收到简历后就可以进行简历筛选，选中合适的人才，再邀请面试，面试成功则可以录用，完成招聘，否则继续筛选人才。
个人模块以及负责难点，后台管理员模块，前台首页的展示，首页包含前台用户各个功能模块的入口。难点在用消息队列rocketMQ实现系统喊话功能。重点突破的模块就是使用redis解决首页的访问并发高峰，以及使用redis的计数器来完成实时的系统内就业人数的统计，求职人数统计，岗位总数统计，课程视频实时点击量，高校就业人数排行榜，这些都涉及到redis的应用场景。
整个项目的最大收获就是学习了大量与redis解决高并发的相关知识。
首先redis remote dictionary server 远程字典服务，是非关系型内存数据库。
就上面项目介绍所说的首页访问高峰，以及提到的热点数据，一旦qps上去,传统的db根本扛不住，导致数据库被打死,系统瘫痪,因此我们需要缓存中间件,就不用每次访问都连接数据库,而是一部分请求会直接到缓存(高速储存器,解决高并发的有效手段,优先从缓存读取数据)这里。
传统db与redis的对比(db的缺陷)
数据存储方式对比：
传统db如oracal mysql都属于关系型数据库，数据都是存在硬盘中，硬盘中的数据虽然可以永久保存，但是读写慢。
redis储存数据在内存中，因此读写性能优异.
(tip:硬盘是机械结构,先将磁信号转化为电信号,而内存没有机械结构,是电,瞬间到达,这就造成了硬盘与内存读写性能的差异)
查询方式对比
传统db查询就是遍历整张表,查询复杂度高,而redis储存数据的形式是key-value,因此通过键即可获取值,极大的降低查询复杂度.
性能方面,如果单纯使用db,则整个系统会非常慢,查询一个数据等半天.
上诉提及,redis将数据保存在内存中,那断电宕机了怎么办?数据岂不是就丢失了.那么redis是如何将数据持久化的呢?这里就涉及到Redis的RDB(redis database)以及AOF(append only file)两种持久化方案.
RDF是redis的默认持久化方案,以快照的形式记录当下时刻的数据,优点是速度快,缺陷就是服务器断电,会导致部分数据丢失.
AOF 就是把将redis数据库的增删改查记录在文件,当数据库恢复时重新执行一遍命令,速度慢,但是能确保数据的完整性.
上述提到的计数器,如排行榜,视频播放量,要求实时性,写的频率高,对数据库有极大的挑战,这就涉及到了redis的数据类型,String.
redis提供的incr(递增X),incrby(key中的数值加上x),以及岗位人数招满了,做递减decr,decrby来处理这些场景.
此外登录涉及到的redis共享session,涉及到高并发的时候,我们要用多台tomcat服务器,那么如果服务器A有了session信息,服务器B没有,就会被打回登录界面,查无此人,就我们上面所涉及到的传统db的缺陷,将每台服务器的session信息保存在数据库,显然不合理,这时候我们就用到redis缓存中间件来实现session共享.