redis分布式

限流必然是很有价值的，在系统资源不足时面对外部世界的不确定性（突发流量，超预期的用户）而形成的一种自我保护机制。 但是价值感是很低的，因为99.99%的时候系统总是工作在安全线之下，甚至一年到头都碰不到一次撞线的机会。这就好比法律，它始终存在，但是大部分时候对于大多数人它几乎不存在，或者说感知不到它的存在。 一、限流的作用 由于API接口无法控制调用方的行为，因此当遇到瞬时请求量激增时，会导致接口占用过多服务器资源，使得其他请求响应速度降低或是超时，更有甚者可能导致服务器宕机。 限流(Rate limiting)指对应用服务的请求进行限制，例如某一接口的请求限制为100个每秒,对超过限制的请求则进行快速失败或丢弃。 限流可以应对： 热点业务带来的突发请求； 调用方bug导致的突发请求； 恶意攻击请求。 因此，对于公开的接口最好采取限流措施。 二、为什么要分布式限流 当应用为单点应用时，只要应用进行了限流，那么应用所依赖的各种服务也都得到了保护。 但线上业务出于各种原因考虑，多是分布式系统，单节点的限流仅能保护自身节点，但无法保护应用依赖的各种服务，并且在进行节点扩容、缩容时也无法准确控制整个服务的请求限制。 而如果实现了分布式限流，那么就可以方便地控制整个服务集群的请求限制，且由于整个集群的请求数量得到了限制，因此服务依赖的各种资源也得到了限流的保护。 三、限流的算法

1 、背景 Redis的出现确实大大地提高系统大并发能力支撑的可能性，转眼间Redis的最新版本已经是3.X版本了，但我们的系统依然继续跑着2.8，并很好地支撑着我们当前每天5亿访问量的应用系统。想当年Redis的单点单线程特性无法满足我们日益壮大的系统，只能硬着头皮把Redis“集群化”负载。且这套“集群化”方案良好地运行至今。虽难度不高，胜在简单和实用。无论简单还是很简单，记录这种经历是一件非常有趣的事情。 2 、问题 系统访问量日益倍增，当前的Redis单点服务确实客观存在连续可用性以及支撑瓶颈风险，这种主/备模式在服务故障突发的情况下就会被动停止服务进行Redis节点切换。针对单点问题，我们结合自身的业务应用场景对Redis“集群化”提出几个主要目标： 1、避免单点情况，确保服务高可用； 2、紧可能把数据分布式存储，降低故障影响范围，满足服务灵活伸缩； 3、控制“集群化”的复杂度，从而控制边际成本； 3 、过程 以上目标1和2就是所谓的分布式集群方案，把大问题分而治之。但最难把控的是目标3的“简化”实现。基于当时开源社区的那几种Redis集群方案，对于我们“简化”的要求来说相对略显臃肿。所以还是决定结合自身的业务应用等因素打造一个“合适”的Redis集群。 初始，我们凭借自己对分布式集群的认识勾结合应用场景勾勒出一个我们觉得足够“简化”的设计图，然后在这个“简化

redis 安装配置学习笔记 //wget http://download.redis.io/releases/redis-2.8.17.tar.gz 下载最新版本 wget http://download.redis.io/redis-stable.tar.gz 首先必须要有 gcc 与 make apt-get install gcc apt-get install make 1、解压 root@localhost:~# tar -xvf redis-stable.tar.gz 2、测试 root@localhost:~/redis-stable# ./runtest You need tcl 8.5 or newer in order to run the Redis test 提示需要安装tcl make完成后，在原src目录下，会生成出六个exe(可执行程序)，服务端只需要redis-server.exe即可 3、运行redis 后台方式启动redis ./redis-server & 启动redis客户端链接 ./redis-cli 输入ping 返回pong 即为安装成功 扩展知识： redis-cli用法：redis-cli [OPTIONS] [cmd [arg [arg ...]]] -h <主机ip>，默认是127.0.0.1 -p <端口>，默认是6379

Redis 与其他 key - value 缓存产品有以下三个特点： （1）Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。 （2）Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。 （3）Redis支持数据的备份，即master-slave模式的数据备份。 Redis和Memcached的区别 Redis常被拿来和高性能键值缓存服务器Memcached进行对比：这两者都可以用来存储键值对，彼此的性能也相差无几，但是Redis相对支持更多的数据类型，除了支持键值对之外，还支持list，set，zset，hash等数据结构的存储，而Memcached只能存储普通的字符串键。 Memcached用户只能通过 APPEND 的方式将数据添加到已有的字符串的末尾，并将这个字符串当做列表来使用。但是在删除这些元素的时候，Memcached采用的是通过黑名单的方式来隐藏列表里的元素，从而避免了对元素的读取、更新、删除等操作。相反的Redis的List和Set允许用户直接添加和删除元素。 Redis和Memcached的其他区别如下： 1、Redis和Memcached都是将数据存放在内存中，都是内存数据库。不过Memcached还可用于缓存其他东西，例如图片、视频等等； 2

1、性能 都比较高，性能对我们来说应该都不是瓶颈 总体来讲，TPS方面redis和memcache差不多，要大于mongodb 2、操作的便利性 memcache数据结构单一 redis丰富一些，数据操作方面，redis更好一些，较少的网络IO次数 mongodb支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富 3、内存空间的大小和数据量的大小 redis在2.0版本后增加了自己的VM特性，突破物理内存的限制；可以对key value设置过期时间（类似memcache） memcache可以修改最大可用内存,采用LRU算法 mongoDB适合大数据量的存储，依赖操作系统VM做内存管理，吃内存也比较厉害，服务不要和别的服务在一起 4、可用性（单点问题） 对于单点问题， redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照,无增量复制，因性能和效率问题， 所以单点问题比较复杂；不支持自动sharding,需要依赖程序设定一致hash 机制。 一种替代方案是，不用redis本身的复制机制，采用自己做主动复制（多份存储），或者改成增量复制的方式（需要自己实现），一致性问题和性能的权衡 Memcache本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的hash或者环状的算法，解决单点故障引起的抖动问题。

1、性能 都比较高，性能对我们来说应该都不是瓶颈 总体来讲，TPS方面redis和memcache差不多，要大于mongodb 2、操作的便利性 memcache数据结构单一 redis丰富一些，数据操作方面，redis更好一些，较少的网络IO次数 mongodb支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富 3、内存空间的大小和数据量的大小 redis在2.0版本后增加了自己的VM特性，突破物理内存的限制；可以对key value设置过期时间（类似memcache） memcache可以修改最大可用内存,采用LRU算法 mongoDB适合大数据量的存储，依赖操作系统VM做内存管理，吃内存也比较厉害，服务不要和别的服务在一起 4、可用性（单点问题） 对于单点问题， redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照,无增量复制，因性能和效率问题， 所以单点问题比较复杂；不支持自动sharding,需要依赖程序设定一致hash 机制。 一种替代方案是，不用redis本身的复制机制，采用自己做主动复制（多份存储），或者改成增量复制的方式（需要自己实现），一致性问题和性能的权衡 Memcache本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的hash或者环状的算法，解决单点故障引起的抖动问题。

1.为什么使用redis？ redis是一种典型的no-sql 即非关系数据库 像python的字典一样 存储key-value键值对 工作在memory中 所以很适合用来充当整个互联网架构中各级之间的cache 比如lvs的4层转发层 nginx的7层代理层 尤其是lnmp架构应用层如php-fpm或者是Tomcat到mysql之间 做一个cache 以减轻db的压力 因为有相当一部分的数据 只是简单的key-value对应关系，而且在实际的业务中常常在短时间内迅速变动 如果用关系数据库mysql之类存储 会大大增加对db的访问 导致db的负担很重 因为所有的require中的大部分最后都要汇聚到db 所以如果想要业务稳定 那么解决db的压力 就是关键 所以现在大部分的解决方案就是在db层之上的各级使用多级的no-sql 像memcache redis 等 来为db提供缓冲 2.为什么使用redis-cluster？ 为了在大流量访问下提供稳定的业务，集群化是存储的必然形态 未来的发展趋势肯定是云计算和大数据的紧密结合 只有分布式架构能满足要求 如果没有集群化 何来的分布式？ 3.顺带一提总结一波今天的redis原理之数据持久化 虽然redis这种no-sql一般都是作为cache来服务 但是如果完全没有数据可持久化的方法 那么显得有些单薄 就像memcache 由于这种no

1、什么是Redis 基本概念 ：redis是一个开源的、使用C语言编写的、支持网络交互的、可基于内存也可持久化的Key-Value数据库（非关系性数据库）。 redis的优势 1、速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1) 2、支持丰富数据类型，支持string，list，set，sorted set，hash 3、支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行 4、丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除 2、redis的应用场景 缓存 1、 对于一些要返回给前端数据的缓存，当有大量数据库sql操作时候，为了避免每次接口请求都要去查询数据库，可以把一些数据缓存到redis中，这样是直接从内存中获取数据，速度回增快很多。 2、web端用户，用于登陆缓存session数据，登陆的一些信息存到session中，缓存到redis中 秒杀 对于string 数据类型，因为string 类型是二进制安全的，可以用来存放图片，视频等内容，另外由于Redis的高性能读写功能，而string类型的value也可以是数字，可以用作计数器（INCR,DECR），比如分布式环境中统计系统的在线人数，秒杀等。 排行榜 对于 zset 数据类型，有序的集合，可以做范围查找

ASP.NET Core中间件实现分布式 Session 1. ASP.NET Core中间件详解 1.1. 中间件原理 1.1.1. 什么是中间件 1.1.2. 中间件执行过程 1.1.3. 中间件的配置 1.2. 依赖注入中间件 1.3. Cookies和session中间件 1.3.1. Session 1.3.2. Session保存到Redis中 1.3.3. 实现分布Session 1.4. 总结 1.1. 中间件原理 1.1.1. 什么是中间件 中间件是段代码用于处理请求和响应，通常多个中间件链接起来形成管道，由每个中间件自己来决定是否要调用下一个中间件。 1.1.2. 中间件执行过程 举一个示例来演示中间件的执行过程（分别有三个中间件：日志记录、权限验证和路由）：当请求进入应用程序时，执行执行日志记录的中间件，它记录请求属性并调用链中的下一个中间件权限验证，如果权限验证通过则将控制权传递给下一个中间件，不通过则设置401 HTTP代码并返回响应，响应传递给日志中间件进行返回。 1.1.3. 中间件的配置 中间件配置主要是用 Run 、 Map 和 Use 方法进行配置，三者的不同参见上篇 ASP.NET Core 运行原理剖析 ；简单的中间件可以直接使用匿名方法就可以搞定，如下代码： app.Run(async (context,next) => { await

　　分布式爬虫，可以让很多台电脑都使用同一个的爬虫程序，将爬虫分发得到多台电脑上，这样可以提高爬虫的速度，也就是分布式爬虫。 　　分布式爬虫需要专门的模块scrapy-redis，原生的scrapy框架无法实现分布式爬取，原因在于：（1）scrapy框架中五大核心组件中的调度器只归属于该项目，无法实现被分布式集群共享；（2）scrapy框架中五大核心组件中的调度器管道只接受该项目的数据对象，无法实现被分布式集群共享。 　　 基于scrapy-redis组件的分布式爬虫 scrapy-redis组件中已经封装好了可以被多台机器共享的调度器和管道，可以直接使用并实现分布式数据爬取。要想实现分布式，必须要有共享的调度器队列和共享管道爬（爬取的数据必须存储在redis中，因为是基于scrapy-redis模块，内置封装的方法） 　　　　实现方式有两种： （1）基于该组件的RedisSpider类；（2）基于该组件的RedisCrawlSpider类。 分布式爬取数据案例 　　 东莞阳光网 （ http://wz.sun0769.com/index.php/question/report?page= ）　 　　 1.安装下载scrapy-redis模块 　　　　pip install scrapy-redis 　　 2.创建爬虫项目（基于CrawlSpider来实现） 　　　　scrapy