Redis原理篇 1.发布 订阅模式 1.1列表 的局限 ​ 前面我们说通过队列的 rpush 和 lpop 可以实现消息队列(队尾进队头出),但是消费者需要不停地调用 lpop 查看 List 中是否有等待处理的消息(比如写一个 while 循环).为了减少通信的消耗,可以 sleep()一段时间再消费,但是会有两个问题: 1.如果生产者生产消息的速度远大于消费者消费消息的速度,List 会占用大量的内存. 2.消息的实时性降低. list 还提供了一个阻塞的命令:blpop,没有任何元素可以…

一.简介 1.国际惯例什么是puppet puppet是一种Linux.Unix.windows平台的集中配置管理系统,使用自有的puppet描述语言,可管理配置文件.用户.cron任务.软件包.系统服务等.puppet把这些系统实体称之为资源,puppet的设计目标是简化对这些资源的管理以及妥善处理资源间的依赖关系. puppet采用C/S星状的结构,所有的客户端和一个或几个服务器交互.每个客户端周期的(默认半个小时)向服务器发送请求,获得其最新的配置信息,保证和该配置信息同步.每个puppe…

Redis原理与实践总结 本文主要对Redis的设计和实现原理做了一个介绍很总结,有些东西我也介绍的不是很详细准确,尽量在自己的理解范围内把一些知识点和关键性技术做一个描述.如有错误,还望见谅,欢迎指出. 这篇文章主要还是参考我之前的技术专栏总结而来的.欢迎查看: 重新学习Redis https://blog.csdn.net/column/details/21877.html 使用和基础数据结构(外观) redis的基本使用方式是建立在redis提供的数据结构上的. 字符串 REDIS_STR…

Redis分布式篇 1 为什么 需要 Redis 集群 1.1 为什么需要集群? 1.1.1 性能 ​ Redis 本身的 QPS 已经很高了,但是如果在一些并发量非常高的情况下,性能还是会受到影响.这个时候我们希望有更多的 Redis 服务来完成工作. 1.1.2 扩展 ​ 第二个是出于存储的考虑.因为 Redis 所有的数据都放在内存中,如果数据量大,很容易受到硬件的限制.升级硬件收效和成本比太低,所以我们需要有一种横向扩展的方法 1.1.3 可用性 ​ 第三个是可用性和安全的问题.如果只有…

Redis实战篇 1 Redis 客户端 1.1 客户端通信 原理 客户端和服务器通过 TCP 连接来进行数据交互, 服务器默认的端口号为 6379 . 客户端和服务器发送的命令或数据一律以 \r\n (CRLF 回车+换行)结尾. 如果使用 wireshark 对 jedis 抓包: 环境:Jedis 连接到虚拟机 202,运行 main,对 VMnet8 抓包. 过滤条件:ip.dst==192.168.8.202 and tcp.port in {6379} set qingshan 抓包…

随笔分类 - redis 系列篇 redis 系列27 Cluster高可用 (2) 摘要: 一. ASK错误 集群上篇最后讲到,对于重新分片由redis-trib负责执行,关于该工具以后再介绍.在进行重新分片期间,源节点向目标节点迁移一个槽的过程中,可以会出现该槽中的一部分键值对保存在源节点中,另一部份键值对则保存在目标节点中. 当客户端向源节点发送一个与数据库键有关的命令时,并且命令要处阅读全文 posted @ 2018-12-27 14:41 花阴偷移 阅读(263) | 评论 (0)…

天下武功,无坚不摧,唯快不破! 学习一个技术,通常只接触了零散的技术点,没有在脑海里建立一个完整的知识框架和架构体系,没有系统观.这样会很吃力,而且会出现一看好像自己会,过后就忘记,一脸懵逼. 跟着「码哥字节」一起吃透 Redis,深层次的掌握 Redis 核心原理以及实战技巧.一起搭建一套完整的知识框架,学会全局观去整理整个知识体系. 系统观其实是至关重要的,从某种程度上说,在解决问题时,拥有了系统观,就意味着你能有依据.有章法地定位和解决问题. Redis 全景图 全景图可以围绕两个纬度展开…

特立独行是对的,融入圈子也是对的,重点是要想清楚自己向往怎样的生活,为此愿意付出怎样的代价. 我们通常将 Redis 作为缓存使用,提高读取响应性能,一旦 Redis 宕机,内存中的数据全部丢失,假如现在直接访问数据库大量流量打到 MySQL 可能会带来更加严重的问题. 另外慢慢的从数据库读取放到 Redis 性能必然比不过从 Redis 获取快,也会导致响应变慢. Redis 为了实现无畏宕机快速恢复,设计了两大杀手锏,分别是 AOF(Append Only FIle)日志和 RDB 快照.…

在移动应用的业务场景中,我们需要保存这样的信息:一个 key 关联了一个数据集合,同时还要对集合中的数据进行统计排序. 常见的场景如下: 给一个 userId ,判断用户登陆状态: 两亿用户最近 7 天的签到情况,统计 7 天内连续签到的用户总数: 统计每天的新增与第二天的留存用户数: 统计网站的对访客(Unique Visitor,UV)量 最新评论列表 根据播放量音乐榜单 通常情况下,我们面临的用户数量以及访问量都是巨大的,比如百万.千万级别的用户数量,或者千万级别.甚至亿级别的访问信息.…

在移动应用的业务场景中,我们需要保存这样的信息:一个 key 关联了一个数据集合. 常见的场景如下: 给一个 userId ,判断用户登陆状态: 显示用户某个月的签到次数和首次签到时间: 两亿用户最近 7 天的签到情况,统计 7 天内连续签到的用户总数: 通常情况下,我们面临的用户数量以及访问量都是巨大的,比如百万.千万级别的用户数量,或者千万级别.甚至亿级别的访问信息. 所以,我们必须要选择能够非常高效地统计大量数据(例如亿级)的集合类型. 如何选择合适的数据集合,我们首先要了解常用的统计模式…