rdb

一、简介 1.1 Redis是什么 Redis是一个开源的，使用ANSI C 编写，高性能的Key-Value的NoSQL数据库。 1.2 Redis特点 （1）基于内存 （2）可持久化数据 （3）具有丰富的数据结构类型，适应非关系型数据的存储需求 （4）支持绝大多数主流开发语言，如C、C++、Java、Python、R、JavaScript等。 （5）支持集群模式，高效、稳定。 1.3 数据模型（重点） （1）键值对形式。 （2）Redis的数据结构类型，指的就是Redis值的结构类型。 1.4 Redis作用 （1）本质是数据库，能存储数据。 Redis能灵活处理非关系型数据的读、写问题，是对MySQL等关系型数据库的补充。 新浪微博就是使用Redis集群做数据库。 （2）缓存数据。 所谓缓存，就是将数据加载到内存中后直接使用，而不是每次都通过IO流从磁盘上读取。好处：读写效率高。 而Redis则是将数据直接存储在内存中，只有当内存空间不足时，将部分数据持久化到磁盘上。 二、安装 1.1 说明 Redis官方只提供了源码，并没有提供经过编译之后的安装包。 因此，安装Redis，要先编译、后安装。（即源码安装方式） 1.2 redis安装步骤 # 安装步骤 cd /usr/ local /src wget http://download.redis.io/releases

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 最近，又重新学习了下Redis，深深被Redis的魅力所折服，我才知道Redis不仅能快还能慢（我想也这么优秀o(╥﹏╥)o），简直是个利器呀。 好了，接下来回到我们的话题，我们都知道Redis是一种基于内存的单进程单线程数据库（Redis6.0开始之后支持多线程啦！），处理速度都非常快。那么为何Redis又能慢呢？原来，这里说的慢是指Redis可以设置一些参数达到慢处理的结果。（这就是为什么Redis既能快又能慢啦！） 那接下来开始讲讲我们的楷模Redis在队列中如何实现延时的情况： 在我们日常生活中，我们可以发现， 在淘宝、京东等购物平台上下单，超过一定时间未付款，订单会自动取消。 打车的时候，在规定时间没有车主接单，平台会取消你的单并提醒你暂时没有车主接单。 点外卖的时候，如果商家在10分钟还没接单，就会自动取消订单。 收快递的时候，如果我们没有点确认收货，在一段时间后程序会自动完成订单。 在平台完成订单后，如果我们没有在规定时间评论商品，会自动默认买家不评论。 .......还有很多这样的场景。 这时，我们可以想想为什么要这样做？ 因为这样可以保证商品的库存可以释放给其他人购买，你可以不用一直等待打车却得不到回复，你可以及时换一家店点到外卖。

Redis提供了许多提高和维护高效内存数据库使用的工具。在无需额外配置应用层的前提下，Redis独特的数据类型、指令和命令调优就可以满足应用的需求，但是错误的配置，更确切的说那些机外设备可能导致操作麻烦和性能问题。虽然导致了一些令人头疼的问题，但是解决方案是存在的，而且解决方案可能比我们预期的简单。 本系列文章介绍了使用Redis时遇到的一些令人头疼的问题，以及该解决这些问题。这些内容基于我们在运行上千个Redis数据库实例时的真实经历。 复制缓冲区限制 复制缓冲区主从服务器同步数据时保存数据的内存区域。在一个完整的主从同步中，初始化阶段同步时，主服务器在复制缓冲区中保存数据的变化。初始化阶段完成后，缓冲的内容发送到从服务器。这个过程可能会遇到缓冲区的容量限制，达到最大容量时复制会重新开始。为了避免这种情况，缓冲区需要依据复制过程中变化的类型和数量进行初始化配置。例如，一个小缓冲区可以存储少量的变化数据，但当变化比较多、比较大时，我们需要大缓冲区。一个更复杂的解决方案会更详细的设置缓冲区，避免冗长、大的复杂过程耗尽缓冲区（如果缓冲区太小）。最终，这个解决方案需要微调特定的数据库。 当256MB的硬限制到达时，或者软限制到达且持续60秒时，默认的复制链路会断裂（导致同步从头开始）。许多情况下，特别是写负载高和从服务器带宽不足的情况下，负载过程都无法结束。这可能导致无限循环

RDB模式 1、什么是RDB 每隔一段时间，把内存中的数据写入磁盘，恢复的时候，他会自动从工作区拿出来进行恢复 2、RDB的优劣势 优势 每隔一段时间，全量备份 备份简单，可以直接传输文到其他地方 备份的过程中会fork一个新的进程来进行文件的存储 劣势 发生故障时，会丢失上次备份到当前时间的数据 fork的进程会和父进程一摸一样，会导致内存随时膨胀两倍 手动备份RDB 手动触发有两个命令 save命令 在执行的时候会阻塞Redis的服务，直到RDB文件完成才会释放我们Redis进程恢复读写操作 bgsave命令 执行bgsave的时候会在后台fork一个进程进行RDB的生成，不影响主进程的业务操作 使用RDB恢复数据 只需要将dump.rdb移动到我们redis.conf配置的dir（dir ./）目录下，就会在Redis启动的时候自动加载数据到内存，但是Redis在加载RDB过程中是阻塞的，直到加载完毕才能恢复操作。获取目录位置：redis-cli> config get dir AOF模式 RDB会丢失最后一次备份和系统宕机之间的数据，所以就需要增量备份的过程了，什么是Redis的增量备份，就是AOF，优点像MySQL的Binlog AOF的特点 以日志形式来记录用户的请求和写操作，读操作不会记录 文件是追加的形式而不是修改的形式

可以先想一下自己的部门或项目组是否面临这些问题： 1. 投入很多技术力量做报表，却还是疲于应付 2. 用了高端报表工具和敏捷 BI，却还是不够用 3. 技术高手用来做报表，感觉很浪费 4. 对于频繁多变的报表需求，需要低成本应对方案 专门用于统计分析的报表业务有一个特点，就是业务稳定性非常差。在业务开展过程中会催生很多新的查询需求，而且已实现的查询需求还会经常变化，这就造成了没完没了的报表。所以经常会有这么一段对话 报表没完没了是需求使然，无法规避，只能适应，而目前主要的是问题是普遍缺少一种低成本的方案来适应没完没了的报表。 为什么报表开发成本一直居高不下？ 我们知道，报表工具的主要作用是将报表呈现阶段的开发工具化，使用报表工具可以将原本需要硬编码的工作通过工具来提高生产效率；但报表开发的另一个阶段：数据准备，却仍然在使用原始的硬编码方式处理，有时我们要编写非常复杂的 SQL、存储过程和 JAVA 程序，这样的工作通常要依赖高水平的技术人员才能完成。 另外，采用过于原始手段会带来报表维护困难，复杂的代码无论从编写还是修改都比较困难，这样又会加剧报表开发成本居高不下！ 除了技术原因外，还有应用结构和团队管理方面的因素也会造成报表开发的成本居高不下。在许多应用系统中，报表是耦合在其中的一些功能，而业务系统的技术环境很复杂，这就迫使报表开发人员也要熟悉这些东西

1. 应用场景 缓存：根据键值过期时间设置 请求频率限制：比如短信验证码120秒内只能发送一次，则将标志性的key-value键值对设置过期时间为120秒，用户请求的时候判断一下【 SET key value EX 120 NX 】 排行榜：利用 zset 数据类型 计数器：利用 INCR KEY 命令，key不存在初始化为0，存在则自增1 用户爱好：利用 set集合 ，其特有的命令方法能够计算用户共同爱好 消息队列：利用 list 数据类型的 lpush和brpop 分布式锁：利用 SET key value [EX seconds] [PX milliseconds] [NX|XX] 2.速度快的原因 纯内存访问 底层I/O用多路复用技术epoll实现 单线程避免了线程切换和竞争 3. 数据类型 字符串（String）：内部编码【8个字节长整型：int】【小于等于39个字节的字符串：embstr】【大于39个字节的字符串：raw】 哈希（Hash）：内部编码【元素个数小于512个并且每个值都小于64字节：ziplist-压缩列表】【否则是hashtable-哈希表】 列表（List）：内部编码【元素个数小于512个并且每个值都小于64字节：ziplist-压缩列表】【否则是linkedlist-链表】 集合（Set）：内部编码【元素都是整数并且个数小于512个：intset

Redis 作者在博客正式宣布 Redis 6.0 发布了！！！地址： http://antirez.com/news/132 Redis 6是有史以来改变最大的 Redis 版本，因此即使稳定，也要小心处理，并在投入生产之前对其进行测试，以进行工作量测试。 到目前为止，我们从未发现重大问题，但请务必小心。在收集错误报告时，我们将准备尽快发布 Redis 6.0.1。 GA 版本除了比 RC1 更稳定，还对部分功能进行了重新设计或是进一步的改进。 对客户端缓存某方面的功能进行了重新设计，主要是放弃了“缓存插槽”（caching slot）改为使用键名（key name）。另外还新增了“广播模式”（broadcasting mode），当使用广播模式时，服务器不需要记住每个客户端请求的 key。相反，客户端会订阅 key 的前缀：每当有匹配前缀的 key 被修改时，客户端就会收到通知。 用于主从复制的 RDB 文件如果不再使用会被删除 新的 ACL LOG 命令，可查看不遵循 ACL 权限的客户端（例如访问了无权限的命令和 key，以及验证失败），主要用于调试 ACL 问题。此外还有重新实现的 ACL GENPASS，它使用了基于 SHA256 的 HMAC 加密算法。 改进 PSYNC2 主从复制协议 改进 Redis 命令行的超时选项 提升 RDB 文件的加载速度（～20/30%

作者：一起web编程 链接： http://www.toutiao.com/i6825148720728769028 点赞功能是目前app开发基本的功能 今天我们就来聊聊 点赞、评论、收藏等这些场景的db数据库设计问题。 1. 我们先来看看场景的需求： 显示点赞数量 判断用户是否点过赞，用于去重，必须的判断 显示个人点赞列表，一般在用户中心 显示文章点赞列表 我们先看一下头条和微博的例子 这两个都是具有顶级流量的，后端肯定有复杂的架构，我们今天只谈大众化的方案。 方案 2.1 mysql方案 mysql方案, 随着nosql的流行，大数据的持续热点，但是mysql仍然不可替代，对于大多数的中小项目，低于千万级的数据量，采用mysql分表+cache，是完全可以胜任的，而且稳定性是其他方案无可比拟的： -- 文章表 create table post { post_id int(11) NOT NULL AUTO_INCREMENT, ...... star_num int(11) COMMENT '点赞数量' } -- 用户表 create table user { user_id int(11) NOT NULL AUTO_INCREMENT, ...... star_num int(11) COMMENT '点赞数量' } -- 点赞表 create table star {

主从复制的作用主要包括： 1、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。 2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。 3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点） 分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。 4、读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量； 5、高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。 从节点开启主从复制，有3种方式： （1）配置文件 在从服务器的配置文件中加入：slaveof <masterip> <masterport> （2）启动命令 redis-server启动命令后加入 --slaveof <masterip> <masterport> （3）客户端命令 Redis服务器启动后，直接通过客户端执行命令：slaveof <masterip> <masterport>，则该Redis实例成为从节点。 通过 info replication

# Redis configuration file example. # # Note that in order to read the configuration file, Redis must be # started with the file path as first argument: # # ./redis-server /path/to/redis.conf # Note on units: when memory size is needed, it is possible to specify # it in the usual form of 1k 5GB 4M and so forth: # # 1k => 1000 bytes # 1kb => 1024 bytes # 1m => 1000000 bytes # 1mb => 1024*1024 bytes # 1g => 1000000000 bytes # 1gb => 1024*1024*1024 bytes # # units are case insensitive so 1GB 1Gb 1gB are all the same. ################################## INCLUDES ###################################