Redis

来源：www.jianshu.com/p/df4fbecb1a4b 1 秒杀业务分析 正常电子商务流程 查询商品； 创建订单； 扣减库存； 更新订单； 付款； 卖家发货； 秒杀业务的特性 低廉价格； 大幅推广； 瞬时售空； 一般是定时上架； 时间短、瞬时并发量高； 2 秒杀技术挑战 假设某网站秒杀活动只推出一件商品，预计会吸引1万人参加活动，也就说最大并发请求数是10000，秒杀系统需要面对的技术挑战有： 1、对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动，这个活动具有时间短，并发访问量大的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。 解决方案：将秒杀系统独立部署，甚至使用独立域名，使其与网站完全隔离。 2、高并发下的应用、数据库负载 用户在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器造成负载压力。 解决方案：重新设计秒杀商品页面，不使用网站原来的商品详细页面，页面内容静态化，用户请求不需要经过应用服务。 3、突然增加的网络及服务器带宽 假设商品页面大小200K（主要是商品图片大小），那么需要的网络和服务器带宽是2G（200K×10000），这些网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽。 解决方案

java连接redis无法连接,报异常RedisConnectionException 参考文章： （1）java连接redis无法连接,报异常RedisConnectionException （2）https://www.cnblogs.com/houzheng/p/9909384.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4437974/blog/4889255

前言： 随着笔者的颜值不断提高，用户量的日益增长，传统的单机方案已经不能满足产品的需求。笔者在网上寻遍方案，发现均为人云亦云，一份以毫秒为精度的轮询分布式锁被转发转载上万次。然，该方案没法满足笔者性能要求。故此，笔者研发ELock插件，并发布本文章。 其实集群也好，分布式服务也好。当我们不能保证团队成员的整体素质，那么在某些业务上，分布式锁自然没法避免。 公认开发原则：能不使用分布式锁的，尽可能不使用 举个例子，一个商品交易，需要检查库存、检查余额、扣库存、扣款、变更订单状态。可能很多人觉得，在分布式环境下一定要分布式锁才能安全。 致此，笔者提供一种简单的方案： 订单处理{ if(订单状态!=待支付){ return 该订单已处理; } if(库存不足){ return 库存不足; } if(余额不足){ return 余额不足; } 事务管理(rollbackFor = Exception.class){ //修改订单状态 int changeLine = 执行语句( update 订单表 set status=已支付 where status=待支付 and orderId=订单号); if(changeLine < 1){ return 该订单已处理; } //扣库存 changeLine = 执行语句(update 商品表 set 库存=库存-订单信息.购买数量 where

Redis事务的概念： Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。 总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。 Redis事务没有隔离级别的概念： 批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到。 Redis不保证原子性： Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。 Redis事务的三个阶段： 开始事务 命令入队 执行事务 Redis事务相关命令： watch key1 key2 … : 监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断 （ 类似乐观锁 ） multi : 标记一个事务块的开始（ queued ） exec : 执行所有事务块的命令 （ 一旦执行exec后，之前加的监控锁都会被取消掉 ） discard : 取消事务，放弃事务块中的所有命令 unwatch : 取消watch对所有key的监控 //加入Java开发交流君样：756584822一起吹水聊天 Redis事务使用案例： （1

来源：SapphireCoder https://www.toutiao.com/a6752317753866060299 导读： 在实际项目中Redis常被应用于做缓存，分布式锁、消息队列等。但是在搭建配置好Redis服务器后很多朋友应该会发现和有这样的疑问，为什么Redis默认建立了16个数据库，如下图所示。 一、16个数据库的由来 Redis是一个字典结构的存储服务器，一个Redis实例提供了多个用来存储数据的字典，客户端可以指定将数据存储在哪个字典中。这与在一个关系数据库实例中可以创建多个数据库类似（如下图所示），所以可以将其中的每个字典都理解成一个独立的数据库。 Redis默认支持16个数据库，可以通过调整Redis的配置文件 redis/redis.conf 中的databases来修改这一个值，设置完毕后重启Redis便完成配置。 客户端与Redis建立连接后会默认选择0号数据库，不过可以随时使用SELECT命令更换数据库。 # 切库 redis> SELECT 1 # 默认0号db，切换为1号db OK redis [1] > GET username # 从1号库中获取 username (nil) 在实际项目中则可以通过以Redis配置文件的形式指定数据库，如下图所示 二、正确理解Redis的“数据库”概念 由于Redis不支持自定义数据库的名字

作者：在江湖中coding https://juejin.im/post/5e6097846fb9a07c9f3fe744 性能测试报告 查看了下阿里 Redis 的性能测试报告如下，能够达到数十万、百万级别的 QPS （暂时忽略阿里对 Redis 所做的优化），我们从 Redis 的设计和实现来分析一下 Redis 是怎么做的。 Redis的设计与实现 其实 Redis 主要是通过三个方面来满足这样高效吞吐量的性能需求 高效的数据结构 多路复用 IO 模型 事件机制 1、高效的数据结构 Redis 支持的几种高效的数据结构 string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合） 以上几种对外暴露的数据结构它们的底层编码方式都是做了不同的优化的，不细说了，不是本文重点。 2、多路复用 IO 模型 假设某一时刻与 Redis 服务器建立了 1 万个长连接，对于阻塞式 IO 的做法就是，对每一条连接都建立一个线程来处理，那么就需要 1万个线程，同时根据我们的经验对于 IO 密集型的操作我们一般设置，线程数 = 2 * CPU 数量 + 1，对于 CPU 密集型的操作一般设置线程 = CPU 数量 + 1。 当然各种书籍或者网上也有一个详细的计算公式可以算出更加合适准确的线程数量，但是得到的结果往往是一个比较小的值，像阻塞式 IO

配置文件参数说明 : 1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程 daemonizeno 2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定 pidfile/var/run/redis.pid 3. 指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女AlessiaMerz的名字 port6379 4. 绑定的主机地址 bind127.0.0.1 5.当 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能 timeout300 6. 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose loglevelverbose 7. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null logfile stdout 8. 设置数据库的数量，默认数据库为0，可以使用SELECT<dbid>命令在连接上指定数据库id databases16 9. 指定在多长时间内，有多少次更新操作

如今，缓存系统的应用非常广泛，能够用来提高并发数、数据吞吐量，提高快速响应能力。那么当数据量达到一定程度，单机环境可能就显得有些力不从心了，就需要一个分布式缓存系统。 1. 缓存系统的选择 1.1 缓存分类 如上图所示，首先缓存大致可以分为四大类。 CDN 缓存：CDN 即内容分发网络，CDN 边缘节点将数据缓存起来。 反向代理缓存：如 Nginx 的缓存。 本地缓存：代表的有 EhCache 和 Guava Cache。 分布式缓存：各缓存系统。 1.2 分布式缓存 本文主要探讨各分布式缓存系统，如图 1-1 所示，列出了五种： 其中 EvCache 和 Aerospike 使用场景不是那么通用和广泛。 EvCache：是 Netflix 的基于 Memcached & Spymemcached 的缓存方案。 Aerospike：是可基于 SSD 的 KV NoSQL 数据库。 除此之外，还有三种常见缓存系统。 Tair：阿里开源，跨机房、性能随结点添加线性上升、适用大数据量。Tair 还有三种引擎。 LDB: 基于 google levelDB，支持 KV和类 HashMap 结构，性能稍低，持久化可靠性最高。 MDB: 基于 Memcache，支持 KV 和类 HashMap，性能最优，不支持持久化存储。 RDB: 基于 Redis。 Memcache: 不支持数据同步

Redis事务的概念： Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。 总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。 Redis事务没有隔离级别的概念： 批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到。 Redis不保证原子性： Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。 Redis事务的三个阶段： 开始事务 命令入队 执行事务 Redis事务相关命令： watch key1 key2 … : 监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断 （ 类似乐观锁 ） multi : 标记一个事务块的开始（ queued ） exec : 执行所有事务块的命令 （ 一旦执行exec后，之前加的监控锁都会被取消掉 ） discard : 取消事务，放弃事务块中的所有命令 unwatch : 取消watch对所有key的监控 //加入Java开发交流君样：756584822一起吹水聊天 Redis事务使用案例： （1

点击上方 蓝字 关注我们 前言 在排序算法中，大家可能对桶排序、计数排序、基数排序不太了解，不太清楚其算法的思想和流程，也可能看过会过但是很快就忘记了，但是不要紧，幸运的是你看到了本篇文章。本文将通俗易懂的给你讲解基数排序。 基数排序，是一种原理简单，但实现复杂的排序。很多人在学习基数排序的时候可能会遇到以下两种情况而浅尝辄止： 一看原理，这么简单，懂了懂了(顺便溜了) 再一看代码，这啥啥啥啊？这些的肯定有问题(不看溜了) image-20201113205712629 要想深入理解基数排序，必须搞懂基数排序各种形式(数字类型、等长字符类型、不等长字符)各自实现方法，了解其中的联系和区别，并且也要掌握空间优化的方法(非二维数组而仅用一维数组)。下面跟着我详细学习基数排序吧！ 基数排序原理 首先百度百科看看基数排序的定义： 基数排序（radix sort）属于“分配式排序”（distribution sort），又称“桶子法”（bucket sort）或bin sort，顾名思义，它是透过键值的部份资讯，将要排序的元素分配至某些“桶”中，藉以达到排序的作用，基数排序法是属于稳定性的排序，基数排序法的效率高于其它的稳定性排序法。 基数排序也称为卡片排序，简而言之，基数排序的原理就是多次利用计数排序(计数排序是一种特殊的桶排序)，但是和前面的普通桶排序和计数排序有所区别的是