热点数据(经常会被查询, 但是不经常被修改或者删除的数据), 首选是使用 Redis 缓存, 毕竟强大到冒泡的 QPS 和极强的稳定性不是所有类似工具都有的, 而且相比于 Memcached 还提供了丰富的数据类型可以使用, 另外, 内存中的数据也提供了 AOF 和 RDB 等持久化机制可以选择, 要冷, 热的还是忽冷忽热的都可选.
结合具体应用需要注意一下: 很多人用 spring 的 AOP 来构建 Redis 缓存的自动生产和清除, 过程可能如下:
Select 数据库前查询 Redis, 有的话使用 Redis 数据, 放弃 select 数据库, 没有的话, select 数据库, 然后将数据插入 Redis
update 或者 delete 数据库钱, 查询 Redis 是否存在该数据, 存在的话先删除 Redis 中数据, 然后再 update 或者 delete 数据库中的数据
上面这种操作, 如果并发量很小的情况下基本没问题, 但是高并发的情况请注意下面场景:
为了 update 先删掉了 Redis 中的该数据, 这时候另一个线程执行查询, 发现 Redis 中没有, 瞬间执行了查询 SQL, 并且插入到 Redis 中一条数据, 回到刚才那个 update 语句, 这个悲催的线程压根不知道刚才那个该死的 select 线程犯了一个弥天大错! 于是这个 Redis 中的错误数据就永远的存在了下去, 直到下一个 update 或者 delete.
二, 计数器
诸如统计点击数等应用. 由于单线程, 可以避免并发问题, 保证不会出错, 而且 100% 毫秒级性能! 爽.
命令: INCRBY
当然爽完了, 别忘记持久化, 毕竟是 Redis 只是存了内存!
三, 队列
相当于消息系统, ActiveMQ,RocketMQ 等工具类似, 但是个人觉得简单用一下还行, 如果对于数据一致性要求高的话还是用 RocketMQ 等专业系统.
由于 Redis 把数据添加到队列是返回添加元素在队列的第几位, 所以可以做判断用户是第几个访问这种业务
队列不仅可以把并发请求变成串行, 并且还可以做队列或者栈使用
四, 位操作(大数据处理)
用于数据量上亿的场景下, 例如几亿用户系统的签到, 去重登录次数统计, 某用户是否在线状态等等.
想想一下腾讯 10 亿用户, 要几个毫秒内查询到某个用户是否在线, 你能怎么做? 千万别说给每个用户建立一个 key, 然后挨个记 (你可以算一下需要的内存会很恐怖, 而且这种类似的需求很多, 腾讯光这个得多花多少钱..) 好吧. 这里要用到位操作 -- 使用 setbit,getbit,bitcount 命令.
原理是:
Redis 内构建一个足够长的数组, 每个数组元素只能是 0 和 1 两个值, 然后这个数组的下标 index 用来表示我们上面例子里面的用户 id(必须是数字哈), 那么很显然, 这个几亿长的大数组就能通过下标和元素值 (0 和 1) 来构建一个记忆系统, 上面我说的几个场景也就能够实现. 用到的命令是: setbit,getbit,bitcount
五, 分布式锁与单线程机制
验证前端的重复请求(可以自由扩展类似情况), 可以通过 Redis 进行过滤: 每次请求将 request Ip, 参数, 接口等 hash 作为 key 存储 Redis(幂等性请求), 设置多长时间有效期, 然后下次请求过来的时候先在 Redis 中检索有没有这个 key, 进而验证是不是一定时间内过来的重复提交
秒杀系统, 基于 Redis 是单线程特征, 防止出现数据库 "爆破"
全局增量 ID 生成, 类似 "秒杀"
六, 最新列表
例如新闻列表页面最新的新闻列表, 如果总数量很大的情况下, 尽量不要使用 select a from A limit 10 这种 low 货, 尝试 Redis 的 LPUSH 命令构建 List, 一个个顺序都塞进去就可以啦. 不过万一内存清掉了咋办? 也简单, 查询不到存储 key 的话, 用 MySQL 查询并且初始化一个 List 到 Redis 中就好了.
七, 排行榜
谁得分高谁排名往上. 命令: ZADD(有续集, sorted set)
最近在研究股票, 发现量化交易是个非常好的办法, 通过臆想出来规律, 用程序对历史数据进行验证, 来判断这个臆想出来的规律是否有效, 这玩意真牛! 有没有哪位玩这个的给我留个言, 交流一下呗.
来源: http://www.bubuko.com/infodetail-2853731.html