公司某集群是针对 `微信(为啥这几个字是敏感词汇了。。。)公众号` 的，基本是可以说是完全面向用户的。 这个项目比较老，用户状态是用session来记录的，可能原来是单机运行，所以没有考虑会话层的分布式，后来用户量慢慢增长之后，架构没有随着变化，只是一味的增加了机器，而针对session的共享并没有做太多的操作，而是很暴力的改变了网关的负载均衡策略，让相同cookie的用户流量打在同一台机器上面，也就是说用cookie做的hash，进行负载均衡。 问题： 当早高峰和晚高峰的时候1号机器经常出现CPU满，内存满，然后极端情况出现宕机，而集群中的其他机器运行良好，吃瓜看戏。 当时觉得是偶然现象没去看原因，有一次直接宕机了引起了警惕，我进去jvm日志看了下线程占用都是垃圾回收占用最多，马上看了下jmap的日志，xxxSessionxxx对象和ConcurentHashMap是稳稳的在第四和第五，而且内存占用很高，另外几台机器都很正常，没有这种情况。马上想到有用户流量异常了全打在了这台机器上面，捞了一下accesslog，发现大量的腾讯的IP在请求这台机器，当时脑子一懵，ddos？不可能吧，看了下请求...

> 因为在快递行业，双十一的流量高峰往往是在13，14，15，到现在21号双十一高峰差不多接近尾声，中间遇到了有些问题值得思考 ### 大流量击垮redis集群 1. 12号下午5点20开始，流量洪峰第一波到达，直接击垮了其中一个非常重要redis集群。 我们生产环境有多个redis集群，这是其中最重要的一个，十几G的数据访问速度极慢，连接马上打满了服务器，发生雪崩，客服大量反馈服务不可用，用户投诉。 根本原因暂时还不确定，因为没时间去查，领导也暂时在高峰期不让去查这个重大生产事故，目前的猜测： 1. bgsave导致redis卡住，间接拖垮了这个集群，因为当时的OPS是将近13W，还是蛮恐怖的。 2. 因为双十一前进行了扩充节点，和这台redis集群有关系的机器总共扩了10台，其中每台连接数设置在80左右，然而redis集群的最大连接数当时是设置的3000，没有考虑扩redis连接数。 3. 有人为的在redis集群的某机器上操作了什么命令，导致了卡住。 解决方案：关闭了某直接面向用户的大流量应用，重启redis集群，并且扩大连接数到1W，同时当天晚上紧急迁移走大量的热key到redis4.0的集...

## redis5.0正式版的一些新特性之我见 > 前几天redis的5.0版本正式上线，有很多新特性跟以前的版本不太一样。 1. #### 其中最不一样的就是加了一种新的流数据类型 关于redis的流处理其实可以专门写一篇文章来详细介绍. redis的流处理实现了一套和kafka类似的生产者消费组模式，实现逻辑不一样，但是目标是一样的：允许一组客户端一起消费消息流。 和kafka的区别，Redis流中的消费者group可能在某种程度上类似于基于分区的消费者group，但是要注意的是，Redis流实际是不一样的。partition只是逻辑存在的，消息只是放在一个Redis的key中，因此不同客户端的服务方式取决于谁去准备处理这些新消息，而不是哪个partition客户端从哪个partition读取消息。 2. #### 新的redis模块API：定时器，集群，字典 3. #### RDB 现在可存储LFU 和LRU 信息 redis的持久化方式一般有两种，一种是rdb的，还有一种是aof，rdb就是隔一段时间将内存中的数据记录dump到磁盘上去持久化。 而redis新增的LFU这类的内存逐出...

``` Class.getResource(String path) ``` - path以/开头： 从ClassPath根下获取 - path不以/开头： 默认是从此类所在的包下取资源 ``` ClassLoader.getResource(String path) ``` ClassLoader.getResource的path中不能以/开头，path是默认是从根目录下进行读取的 > 读取jar里面的文件，我们只能用流去读取，不能用File

> Log-Structured Merge Tree 日志结构合并树 下班闲来无事看了下这种树的结构，这种树的结构还是比较简单的，leveldb的存储结构用的就是这种。 简言之就是 将数据划分为多份，每一份存储一部分数据。 每一份数据都是有序的，这样来一个数据进行查询的时候对每一部分可以进行二分查找，速度可以快很多。 真正存储的时候每一部分数据是不进行二分查找的，而是有一个类似于bitmap的结构记录着里面有哪些数据，这样查询的速度又可以增加很多。 由于数据量在增加，所以各个小部分的树之间有可能存在合并重新排序，所以这种结构被称为Log-Structured Merge。