shaolong1013的博客

同步情况下：只有一种线程，接到请求，并继续处理业务异步情况下：分成两部分线程，处理请求线程和工作线程同步模式下，当存在多种场景的业务时，有些业务处理时间较长或者IO等待时间长，比如远程调用，此时线程会被长时间占用，导致线程被占满，无法接收新请求；异步模式下，长时间IO由工作线程去处理，不影响请求的线程处理，当业务处理时间较短的业务请求过来时，处理请求线程任然可以继续处理这部分请求...

一、更新数据库，直接删除缓存二、删除缓存失败情况：1、缓存设置过期时间，一定会保证缓存的最终一致性；2、其他再保证缓存与DB的不一致时间缩短：a、发送mq，消费mq删除对应缓存b、如果mq发送失败，可以写本地日志文件，本地写入肯定会成功。然后从本地日志文件中读取继续重试删除缓存。...

背景：在超大访问量情况下，统计PV值，例如100W的qps利用redis直接计数，redis的累加并发能力最大万级，此情况下可以根据userid来hash出128个key，hash操作在应用中完成，然后应用在不同的key上累加，这些key可以在一个redis集群上，一个集群扛不住可以是多个集群，最后展示累加值得时候，取这128个key的数再相加。...

长轮询：客户端每隔10-20秒发送一次请求，基于上一次请求断开后再发送请求，后端拿到请求后，循环获取数据，获取不到数据情况下可以Thread.sleep(300);一小段时间，然后接着循环，可以循环N次之后无数据直接返回无数据，一次请求完成，然后断开连接，客户端接着发送下一次请求。基于HTTP的长连接,是一种通过长轮询方式实现"服务器推"的技术,它弥补了HTTP简单的请求应答模式的不足,...

背景：群里有几百人，如果为没人存一份消息，消息会极速膨胀。1、在群消息表存储所有人发的消息，并且每条消息都有一个顺序的编号2、群成员表：存储这个群有哪些成员；3、群消息进度表：存储这个群每个成员的读取进度，也就是上次读取到了哪条消息，后面的都是未读的；4、群消息ID，只要在这个群里有序递增即可，跟其他群没有关系，避免不够用；5、同一个群的消息必须存在同一个表中，以群ID为has...

一、推（写入压力大，关联用户较少，如微信朋友圈，一般也就几百个）1、产生很多垃圾信息，用户不看；2、对于敏感信息不能过滤，如黄色、反动信息直接推送给粉丝了，会出大问题，即使后面运营人员发现该条消息违法，要删除也比较困难，已经写入到各个粉丝消息列表中；3、好友删除后，已经推送出去的信息较难收回；二、拉（查询压力大，关联用户非常多，如微博大V，粉丝上亿）如果微博大V采用推的方...

CAP是Consistency、Availablity和Partition Tolerance的缩写。一般的分布式系统最多满足其中两条。而Partition Tolerance是分布式系统的关键，因此都会保留此特性。Eureka是基于AP原则构建的，而ZooKeeper是基于CP原则构建的。这些可以从他们的特性中得到体现。ZK有一个Leader，而且在Leader无法使用的时候通过Paxo...

先看业务，业务是不是需要强一致：弱一致：缓存设定过期时间，过期后自动从db中更新缓存；强一致：使用分布式锁；1、线程A先对该key加上分布式锁（锁一定要设置过期时间！！！）2、线程A删除缓存（其他线程在查询到缓存数据为空时，尝试去获取分布式锁，获取不到锁，说明有线程正在更新缓存数据，则等待锁或者直接查询数据库）3、线程A更新数据库4、线程A更新缓存5、线程A解锁（如...

高并发下单主要包括以下几个方面：分库分表多应用实例全局唯一订单号数据库连接买家查询订单卖家查询订单扩容问题业务拆分一、分库分表随着订单量的增长，数据库的发展主要经历以下几个步骤： - 1主-1从架构 - 双主-多从架构，读写分离 - 表分区，提高并发 - 分表，提高并发 - Master更换SSD - 分库，分表，提高并发分库分表实现过程订单分成16个库，每个库64个表进

后台秒杀架构设计与实现（一）本文只讲处理秒杀请求、减库存操作，前端的CDN加速，防作弊，防刷不在此列；本文利用redis watch实现乐观锁来处理减库存请求。 本文适用于用户量大，商品库存量少场景，若是库存量大场景，适合队列异步实现。流程图 测试入口类package com.liushao.redislockframework;import java.util.Date;import jav