樱桃小窝

Redis五大数据类型Key + string set list hash zset 通用操作指令12345678910111213141516171819#查询当前库的所有键keys * #判断某个键是否存在exists <key> #查看键的类型type <key>#删除某个键del <key>#设置键值对的过期时间 单位:秒expire <key> <seconds>#查看还有多少秒过期 -1永不过期 -2已过期ttl <key>#查看当前数据库key的数量dbsize#清空当前库Flushdb#通杀全部库Flushall String String是Redis最基本的类型,可以理解成与Memcached一模一样的类型,一个key 对应一个value String类型是二进制安全的,意味着redis的string可以包含任何数据.比如jpg图片或者序列化的对象 String类型是redis最基本的数据类型,一个redis中,字符串value最多可以是512M 基本操作指令123456789101 ...

一、分布式事务前奏 事务：事务是由一组操作构成的可靠的独立的工作单元，事务具备ACID的特性，即原子性、一致性、隔离性和持久性。 本地事务：当事务由资源管理器本地管理时被称作本地事务。本地事务的优点就是支持严格的ACID特性，高效，可靠，状态可以只在资源管理器中维护，而且应用编程模型简单。但是本地事务不具备分布式事务的处理能力，隔离的最小单位受限于资源管理器。 全局事务：当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局的事务状态和参与的资源，协同资源的一致提交回滚。 TX协议：应用或者应用服务器与事务管理器的接口。 XA协议：全局事务管理器与资源管理器的接口。XA是由X/Open组织提出的分布式事务规范。该规范主要定义了全局事务管理器和局部资源管理器之间的接口。主流的数据库产品都实现了XA接口。XA接口是一个双向的系统接口，在事务管理器以及多个资源管理器之间作为通信桥梁。之所以需要XA是因为在分布式系统中从理论上讲两台机器是无法达到一致性状态的，因此引入一个单点进行协调。由全局事务管理器管理和协调的事务可以跨越多个资源和进程。全局事务管理器一般使用XA二阶段协议 ...

RabbitMQ消息队列MQ概述MQ全称Message Queue(消息队列),是在消息的传输过程中保存消息的容器.多用于分布式系统之间进行通信 分布式系统通信方式: 直接远程调用 借助第三方完成间接通信 MQ的优势: 应用解耦 异步提速 削峰填谷 MQ的劣势: 系统可用性降低 AB系统没问题 还需要保证MQ没问题 引入的外部依赖越多,系统稳定性越差 系统复杂度提高 如何保证消息没有重复消费 没有丢失 保证顺序性 一致性问题 给BCD三个系统 如果其中一个处理失败如何处理 使用MQ的前提: 生产者不需要从消费者获得反馈 容许短暂的不一致性 使用收益超过加入成本 RabbitMQ简介常用的MQ产品,各有侧重 RabbitMQ是一个由erlang开发的AMQP(Advance Message Queue Protocol)的开源实现 AMQP: 高级消息队列协议,是一个网络协议,是应用层协议的一个开放标准,为面向消息的中间件设计.基于此协议的客户端与消息中间件可传递消息,并不 受客户端/中间件不同产品,不同开发语言的限制.2006年 AMQP规范发布.类比Http ...

Redis缓存穿透和雪崩Redis缓存的使用 极大的提升了应用程序的性能和效率 特别是数据查询方面 但同时也带来了一些问题 其中最要害的问题就是 数据的一致性问题 从严格意义上讲 这个问题无解 如果对数据的一致性要求很高 那么就不能使用缓存 另外一些典型问题就是 缓存穿透 缓存雪崩 缓存击穿 缓存穿透概念缓存穿透的概念很简单 用户想要查询一个数据 发现redis内存数据库没有 缓存没有命中 于是向持久层数据库查询 发现也没有 于是本次查询失败 当用户很多的时候 缓存都没有命中 于是都去请求了持久层数据库 这会给持久层数据库造成很大的压力 这时候就相当于 出现了缓存穿透 风险 利用不存在的数据进行攻击 造成数据库压力过大 解决方案布隆过滤器布隆过滤器是一种数据结构 对所有可能查询的参数以hash形式存储 在控制层先进行校验 不符合则丢弃 从而避免了对底层存储系统的查询压力 缓存空对象当存储层不命中后 即使返回的空对象也将其缓存起来 同时会设置一个过期时间 之后再访问这个数据将会从缓存中获取 保护了后端数据库 存在两个问题 如果空值能被存储起来 这就意味着缓存需要更多的空间存储更多 ...

Redis持久化(重点)Redis是内存数据库 如果不将内存中的数据库状态保存到磁盘 那么一旦服务器进程退出 服务器中的数据库状态也会消失 所以redis提供了持久化功能 RDB(Redis DataBase)什么是RDB? 在指定的时间间隔将内存中的数据集快照写入磁盘 也就是行话讲的snapshot 恢复时直接将快照文件读到内存里 Redis会单独创建(fork)一个子进程来进行持久化 会将数据写入到一个临时文件中 待持久化过程都结束了 再用这个临时文件替换上次持久化好的文件 整个过程中 主进程是不进行任何IO操作的 这就确保了极高的性能 如果需要进仓库大规模的恢复 且对于数据恢复的完整性不是特别敏感 那RDB方式要比AOF方式更高效 RDB的缺点是 最后一次持久化后的数据可能丢失 默认就是RDB 不需要修改 RDB保存的文件 ==dump.rdb== 生产环境有时候会将这个文件备份 都是在我们配置文件中的快照进行配置的 1dbfilename dump.rdb 触发机制 save规则满足的情况下 会自动触发rdb规则 执行flushall 也会触发rdb规则 退出redis ...

Redis.conf详解启动的时候 通过配置文件启动 配置文件unit单位 对大小写不敏感 include包含 include /path/to/local.conf 网络 bind 127.0.0.1 保护模式 Protected-mode yes 端口 port 6379 是否以守护进程方式运行 daemonize yes 如果以后台方式运行 我们就需要指定一个pid文件 pidfile /var/run/redis_6379.pid 日志级别 loglevel notice 生成的日志文件名 logfile "" 默认的数据库数量 databases 16 logo显示(正方形那个) always-show-logo yes 持久化 在规定时间内 执行了多少次操作 则会持久化到文件 rdb.aof redis 是内存数据库 如果没有持久化 那么数据断电即失 如果 900 s内 至少有1个key修改了 就进行持久化操作 save 900 1 save 300 10 save 60 10000 持久化出现 ...

Redis入门 从自己之前做的笔记整理 可能有点混乱 会慢慢修改 NoSQL入门概述 为什么用nosql?90年代 一个网站的访问量 一般都不大 单个数据库 完全可以轻松应付. 在那个时候 更多的都是静态网页 动态交互类型的网站不多,随着访问量上升 几乎大部分的mysql架构的网站 在数据库上都开始出现了性能问题 web程序 不再仅仅专注在功能上 同时也追求性能 程序员开始大量使用缓存技术来缓解数据库的压力 优化数据库的结构和索引 由于数据库的写入压力增加 而Memcached只能缓解数据库的读取压力; 读写集中在一个 数据库上让数据库 不堪重负 大部分网站开始使用 主从复制技术来达到读写分离 以提高读写性能和读库的扩展性 Mysql的master-slave模式成为 这个时候网站标配 数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。 时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。 也 ...

Session共享问题session就是服务器里的一个内存数据 Session共享问题分布式下session共享问题 不同域名不能共享 同一个服务,复制多份,session不同步问题 不同服务,session不能共享 Session共享解决session复制 优点: web-server(Tomcat)原生支持,只需要修改配置文件 缺点 session同步需要数据传输,占用大量网络带宽,降低服务器群的业务处理能力 任意一台web-server保存的数据都是所有web-server的session总和,受到内存限制无法水平拓展更多server 大型分布式集群情况下,由于所有的web-server都全量保存数据,所以不可取 客户端存储 优点 服务器不需要存储sessio,用户保存自己的session信息到cookie中.节省服务端资源 缺点 都是缺点,基本不可能使用 每次http请求,携带用户cookie中的完整信息,浪费网络带宽 session数据放在cookie中,cookie有长度限制4k,不能保存大量信息 session数据放在cookie中,存在泄漏,篡改,窃 ...