白天不懂夜的黑的博客

其实这是分库分表之后你必然要面对的一个问题，需要一个全局唯一的 id 来支持一.全局唯一id–基于数据库的实现方案1.1 数据库自增 id这个就是说你的系统里每次得到一个 id，都是往一个库的一个表里插入一条没什么业务含义的数据，然后获取一个数据库自增的一个 id。拿到这个 id 之后再往对应的分库分表里去写入。这个方案的好处就是方便简单，谁都会用；缺点就是单库生成自增 id，要是高并...

一.分表分表:就是把一个表的数据放到多个表中，然后查询的时候你就查一个表。比如按照用户 id 来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在 200 万以内。二.分库分库是啥意思？就是你一个库一般我们经验而言，最多支撑到并发 2000，一定要扩容了，而且一个健康的单库并发值你最好保持在每秒 1...

一.介绍session:session 是啥？浏览器有个 cookie，在一段时间内这个 cookie 都存在，然后每次发请求过来都带上一个特殊的 jsessionid cookie，就根据这个东西，在服务端可以维护一个对应的 session 域，里面可以放点数据。一般的话只要你没关掉浏览器，cookie 还在，那么对应的那个 session 就在，但是如果 cookie 没了，session...

一.分布式事务的实现主要有以下 5 种方案XA 方案TCC 方案(*)本地消息表可靠消息最终一致性方案(**)最大努力通知方案二.两阶段提交方案/XA方案所谓的 XA 方案，即：两阶段提交，有一个事务管理器的概念，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个...

一.zookeeper 的使用场景如下分布式协调分布式锁元数据/配置信息管理HA高可用性二.分布式协调这个其实是 zookeeper 很经典的一个用法，简单来说，就好比，你 A 系统发送个请求到 mq，然后 B 系统消息消费之后处理了。那 A 系统如何知道 B 系统的处理结果？用 zookeeper 就可以实现分布式系统之间的协调工作。A 系统发送请求之后可以在 zookeeper...

一.消费端的限流RabbitMQ提供了一种qos(服务质量保证)功能, 即在非自动确认消息的前提下, 如果一定数目的消息(通过consumer或者channel设置qos的值)未被确认前, 不进行消费新的消息.自动签收要设置成false, 建议实际工作中也设置成falsevoid basicQos(int prefetchSize, int prefetchCount, boolean gl...

一. 什么是生产端 confirm确认机制消息确认的理解:是指生产者投递消息后, 如果Broker收到消息, 则会给我们产生一个应答,生产者进行接收应答, 用来确定这条消息是否正常发送到Broker, 这种方式也是消息的可靠性投递的核心保障二. 在生产端实现confirm确认机制在channel上开启确认模式 : channel.confirmSelect()在channel上添加监听 ...

一.什么是生产端可靠性投递;

一 实现的原理:利用Zookeeper瞬时有序节点的特性多线程并发创建瞬时节点时,得到有序的序列序号最小线程获取锁其它线程监听自己序号的前一个序号前一个线程执行完成,删除自己序号的节点下一个序号的线程得到通知,继续执行二.zookeeper的Curator客户端实现分布式锁...

redis分布式锁基于redis的setnx实现分布式锁的一.redis分布式锁的原理:sex key value nx time1.利用nx原子性,多个线程并发的时候,只有一个线程可以设置成功2.设置成功既获取到锁,可以执行后续的业务处理3.如果出现异常,过了锁的有效期,锁自动释放4.释放锁采用redis的delete命令5.释放锁校验之前设置的随机数 ,只有随机数相同才释放6...