网站排版图片,网站禁止右键,广州珠江工程建设监理有限公司网站,网络推广浏览目标一、前言 在大多数传统的web系统中#xff0c;使用Redis一般都是作为缓存使用#xff0c;在大数据查询时作为缓解性能的一种解决方案。博主的的系统中使用Redis也主要使用到缓存的作用#xff0c;还有做了注册中心#xff0c;分布式事务。其他的强大的功能#xff0c;没有…一、前言 在大多数传统的web系统中使用Redis一般都是作为缓存使用在大数据查询时作为缓解性能的一种解决方案。博主的的系统中使用Redis也主要使用到缓存的作用还有做了注册中心分布式事务。其他的强大的功能没有运用上。下面看一张图看看Redis高阶还能用到哪些常见的场景。 二、Redis高阶用法  消息队列Redis的列表数据结构非常适合作为简单的消息队列。消息发布者可以使用LPUSH命令向队列中添加消息而多个消息订阅者则可以通过阻塞线程使用BRPOP命令从队列中取出消息。需要注意的是Redis官方并不提供可靠消费/发布的机制因此需要自行实现故障转移、队列持久化、队列监控和流量控制等功能。Lua脚本Redis支持使用Lua脚本在服务器端执行一系列命令。这有助于减少客户端与服务器之间的网络开销并且可以实现复杂的原子操作。事务Redis支持事务可以将一系列命令作为一个原子操作来执行。这通过MULTI、EXEC、DISCARD和WATCH等命令来实现确保在事务执行期间中间步骤不会被其他客户端打断。分布式锁Redis可以利用SET命令的NX不覆盖参数来实现分布式锁。获取锁的客户端可以执行临界区的代码而其他客户端则需要等待锁的释放。 public String lock(String key, int timeOutSecond) {for (; ; ) {String stamp String.valueOf(System.nanoTime());boolean exist redisTemplate.opsForValue().setIfAbsent(key, stamp, timeOutSecond, TimeUnit.SECONDS);if (exist) {return stamp;}} } public void unlock(String key, String stamp) {redisTemplate.execute(script, Arrays.asList(key), stamp); } 排行榜Redis的有序集合数据结构zset非常适合用来实现排行榜功能。例如可以通过zadd命令添加分数和成员然后使用zrevrange命令获取排名最高的成员。HyperLogLog这是Redis用于基数统计的算法。当输入元素的数量或体积非常大时HyperLogLog所需的计算空间总是固定的且很小。通过pfadd命令添加元素然后使用pfcount命令获取基数统计结果。过期键管理Redis可以为键设置过期时间过期后键会自动被删除。这对于缓存系统特别有用可以避免长时间占用内存。 redis的数据结构丰富一般不会在功能性上造成困扰。但随着请求量的增加SLA要求的提高我们势必会对Redis进行一些改造和定制性开发。 高可用挑战 redis提供了主从、哨兵、cluster等三种集群模式其中cluster模式为目前大多数公司所采用的方式。 但是redis的cluster模式有不少的硬伤。redis cluster采用虚拟槽的概念把所有的key映射到 016383个整数槽内属于无中心化的架构。但它的维护成本较高slave也不能够参与读取操作。 它的主要问题在于一些批量操作的限制。由于key被hash到多台机器上所以mget、hmset、sunion等操作就非常的不友好经常发生性能问题。 redis的主从模式是最简单的模式但无法做到自动failover通常在主从切换后还需要修改业务代码这是不能忍受的。即使加上haproxy这样的负载均衡组件复杂性也是非常高的。 哨兵模式在主从数量比较多的时候能够显著的体现它的价值。一个哨兵集群能够监控成百上千个集群但是哨兵集群本身的维护是比较困难的。幸运的是redis的文本协议非常简单在netty中甚至直接提供了redis的codec。自研一套哨兵系统加强它的功能是可行的。 冷热数据分离 redis的特点是不管什么数据都一股脑地搞到内存里做计算这对于有时间序列概念有冷热数据之分的业务造成了非常大的成本考验。为什么大多数开发者喜欢把数据存放在MySQL中而不是Redis中除了事务性要求以外很大原因是历史数据的问题。 通常这种冷热数据的切换是由中间件完成的。我们上面也谈到了Redis是一个文本协议非常简单。做一个中间件或者做一个协议兼容的Redis模拟存储是比较容易的。 比如我们Redis中只保留最近一年的活跃用户。一个好几年不活跃的用户突然间访问了系统这时候我们获取数据的时候就需要中间件进行转换从容量更大速度更慢的存储中查找。 这个时候Redis的作用更像是一个热库更像是一个传统cache层做的事情发生在业务已经上规模的时候。但是注意直到此时我们的业务层代码一直都是操作的redis的api。它们使用这众多的函数指令并不关心数据到底是真正存储在redis中还是在ssdb中。 功能性需求 redis还能玩很多花样。举个例子全文搜索。很多人都会首选es但redis生态就提供了一个模块RediSearch可以做查询可以做filter。 但我们通常还会有更多的需求比如统计类、搜索类、运营效果分析等。这类需求与大数据相关即使是传统的DB也不能胜任。这时候我们当然要把redis中的数据导入到其他平台进行计算啦。 如果你选择的是redis数据库那么dba打交道的就是rdb而不是binlog。有很多的rdb解析工具(比如redis-rdb-tools)能够定期把rdb解析成记录导入到hadoop等其他平台。 此时rdb成为所有团队的中枢成为基本的数据交换格式。导入到其他db后的业务该怎么玩怎么玩完全不会因为业务系统选用了redis就无法运转。