Kindle_code的专栏

什么是流量削峰 秒杀这一场景，削峰的本质是更多的延缓用户请求的发出，以便减少和过滤一些无效的请求，遵从“请求数尽量少”的原则 为什么要用 削峰的存在，一是可以让服务器端处理变的更加平稳，二是节省服务器资源成本。 实现思路 排队、答题、分层过滤 排队 1、利用线程池加锁等待 2、先进先出、仅仅后出等常用的内存排队算法 3、请求序列化文件，然后再顺序读文件恢复请求 答题 作用: 1、防作弊。2、延缓请求 答题模块三部分 1、题库生成，重要防止机器算出结果 2、题库推送模块，秒杀答题前，把题目提前推送给详情和交

线程池是什么、为什么要用线程池 参考 美团线程池实现原理介绍 参数的原始构造 ThreadPoolExecutor( int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue,

什么是热点: 热点分为热点操作和热点数据。热点数据又分为静态热点数据和动态热点数据 发现热点数据: 发现静态热点数据: 1、静态热点数据可通过强制卖家报名，提前把商品筛选，然后通过后台系统将热点商品进行预处理（提前进行缓存），不过增加了卖家的使用成本，也不够灵活 2、通过技术手动进行提前预测，大数据分析，统计TOPN商品 发现动态热点数据: 可以通过大数据预测等手动提前预测，但是实时性较差 1、构建一个异步系统，可收集交易链路上各个环节的中间件产品的热点key,如Nginx、缓存、RPC服务框架等（一些中间

何为动静数据 “动态数据”和“静态数据”的主要区别就是看页面中输出的数据是否和 URL、浏览者、时间、地域相关，以及是否含有 Cookie 等私密数据。比如说： 1、媒体类网站，无论谁访问，文章内容都一样，典型的静态资源 2、页面上的个性化推荐与个人信息等为动态数据 静态数据如何缓存呢 1、将静态数据缓存在用户最近的地方。常见的有三种: · 用户浏览器 · CDN上 · 服务器的Cache上 2、静态化改造就是直接缓存HTTP连接。静态化缓存HTTP连接不是仅仅缓存数据，就连HTTP协议都不用重新组装

重温许令波老师的秒杀系统课程 课程链接 架构基本原则: “4要1不要” 1、数据尽量少：数据网络传输，序列化，编码，解压等操作消耗CPU，数据越简单、越小则好 简化秒杀页面大小，去掉不必要的页面装修等 2、请求数量尽量少: 减少额外的请求，TCP等都耗时较多 3、路径尽量短: 远程调用都会创建scoket连接，也会增大服务不可用的可能性的叠加 4、依赖尽量少: 用户访问一个页面所依赖的系统，防止关键系统被弱依赖系统拖累 5、不要单点: 服务单点不可用 最初版本的秒杀系统 把你的商品购买页面增加一个“定时

主要讨论的功能 (基于高流量高并发的场景) 评论资源 评论总数的更新 评论点赞 精彩评论的读取 评论表设计(简约版) 这是资源通用的表设计 高并发下的问题 热点数据并发量极高 评论的新增，更新CommentResource的评论总数，存在并发问题 评论的点赞数也是同样的问题 四大业务模块详解 评论发表，如下图 通过异步化的操作，来解决行锁竞争给核心资源MYSQL带来压力，保证系统平稳平滑。 在异步化的场景下，同时带来的问题 1、评论的有序性质: 评论的发布本周没有逻辑上的有序，最终展示通过发

应用场景 Redis官方介绍,Redis单机读写性能12万/s,批量处理能达到70w/秒。不管是缓存还是数据库，都有批量处理能力。当系统达到瓶颈时，才充分考虑压榨心梗。适用于电商双十一，特定高并发场景。 思路 1、一个用户请求到来时，将请求放在一个队列中，单线程定时任务10ms从队列中取数据进行处理。 2、定时任务，把队列中的请求，批量的方式向后端和Redis缓存或数据库发起批量请求。 3、请求合并，请求阻塞等待请求处理完毕，需要用到Future 代码实现: /** * @author MrCai

原理 一个很长的二进制向量和一系列随机映射函数 。 通过设置向量数组长度与定义多种随机hash函数，正向预热数据，反向查询数据。使用的hash函数越多，区分度就越高。 图解: 使用场景 大数据判断是否存在：这就可以实现出上述的去重功能，如果你的服务器内存足够大的话，那么使用 HashMap 可能是一个不错的解决方案，理论上时间复杂度可以达到 O(1 的级别，但是当数据量起来之后，还是只能考虑布隆过滤器。 解决缓存穿透：我们经常会把一些热点数据放在 Redis 中当作缓存，例如产品详情。 通常一