这篇文章完全是因为做到了文章点击量的功能的时候，数据库的读写速度已经逐渐满足不了我的项目了[因为有很多的数据库操作嘛]。
正一筹莫展的时候，在技术网站上面看到了一篇文章名字叫做"Redis 解决高并发思路"的论文引起了我的注意。
redis其实也不是没想过，但是之前看到了一个业界大佬不断的呼吁'stateless'的服务，也就是不要让随随便便的程序附加上一些繁琐的附加程序。比如说java+ mysql就能完成的任务非要加上一些redis、mq啊什么什么的，因为加上那些程序的话你们的后台程序的存活性就会变相对低一些，因为还要考虑到这些附加程序的健康性。
理念不舍弃，程序照样用
因为涉及到了文章的点击量了嘛，所以即使就算你的QPS是那小小的个位数字，但是那样来说到服务器里面取文章并且对文章进行各种修饰(带上作者信息啊、评论信息啊、点赞数啊etc..)也对数据库造成了一个不小的压力，所以Redis是解决服务器压力的一大利器！！
数据库设计
这里我们就要唠一唠了，数据库如何设计呢？
看了好多大佬的文章，大概总结出了这样的一个道理，那就是数据分离。
数据是分成了冷热两大数据的，比如说用户信息这种不经常修改的信息就是冷数据，而那些像是用户登录时间和操作啊那些经常进行刷新数据的就是热数据。
所以我们需要将点赞单独分出来
也就是我们经常的老三样
- BLOG
| id | title | ... |
|---|---|---|
| 文章Id | 文章名称 | 闲杂文件 |
- USER
| id | username | pwd | salt |
|---|---|---|---|
| 用户id | 用户名称 | 密码 | 盐 |
- USER_CLICK_BLOG
| BLOG_ID | USER_ID | DATE |
|---|---|---|
| 文章id | 用户id | 时间 |
是不是很熟悉？对，就是我们大学经常讲的多对多模型。
这里插一点，经过最近对mybatis逆向工程进行的分析。发现里面有一个可优化的点，就是查询当前表下的所有数据的时候，如果你的表里面只有一个字段作为字段的时候，尽量将代码count(*)改成count(PK)