摘要：
资源隔离，两种策略，线程池隔离，信号量隔离 对资源隔离这一块东西，做稍微更加深入一些的讲解，告诉你，除了可以选择隔离策略以外，对你选择的隔离策略，可以做一定的细粒度的一些控制 1、execution.isolation.strategy 指定了HystrixCommand.run()的资源隔离策略， 阅读全文
摘要：
（1）数据库自增id 这个就是说你的系统里每次得到一个id，都是往一个库的一个表里插入一条没什么业务含义的数据，然后获取一个数据库自增的一个id。拿到这个id之后再往对应的分库分表里去写入。 这个方案的好处就是方便简单，谁都会用；缺点就是单库生成自增id，要是高并发的话，就会有瓶颈的；如果你硬是要改 阅读全文
摘要：
（1）如何实现mysql的读写分离？ 其实很简单，就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。 （2）MySQL主从复制原理的是啥？ 主库将变更写binlog日志，然后从库连接到主库之后，从库有一个IO线程，将主库的bin 阅读全文
摘要：
（1）停机扩容 这个方案就跟停机迁移一样，步骤几乎一致，唯一的一点就是那个导数的工具，是把现有库表的数据抽出来慢慢倒入到新的库和表里去。但是最好别这么玩儿，有点不太靠谱，因为既然分库分表就说明数据量实在是太大了，可能多达几亿条，甚至几十亿，你这么玩儿，可能会出问题。 从单库单表迁移到分库分表的时候， 阅读全文
摘要：
假设，你现有有一个单库单表的系统，在线上在跑，假设单表有600万数据 3个库，每个库里分了4个表，每个表要放50万的数据量 假设你已经选择了一个分库分表的数据库中间件，sharding-jdbc，mycat，都可以 你怎么把线上系统平滑地迁移到分库分表上面去 sharding-jdbc：自己上官网， 阅读全文
摘要：
（1）为什么要分库分表？（设计高并发系统的时候，数据库层面该如何设计？） 说白了，分库分表是两回事儿，大家可别搞混了，可能是光分库不分表，也可能是光分表不分库，都有可能。我先给大家抛出来一个场景。 假如我们现在是一个小创业公司（或者是一个BAT公司刚兴起的一个新部门），现在注册用户就20万，每天活跃 阅读全文
摘要：
其实所谓的高并发，如果你要理解这个问题呢，其实就得从高并发的根源出发，为啥会有高并发？为啥高并发就很牛逼？ 我说的浅显一点，很简单，就是因为刚开始系统都是连接数据库的，但是要知道数据库支撑到每秒并发两三千的时候，基本就快完了。所以才有说，很多公司，刚开始干的时候，技术比较low，结果业务发展太快，有 阅读全文
摘要：
01_单块系统里的事务 0202_分布式系统里的事务 03_两阶段提交方案 04 TCC方案 05 本地消息表方案 06 可靠消息最终一致性方案 07_最大努力通知方案 阅读全文
摘要：
1）两阶段提交方案/XA方案 也叫做两阶段提交事务方案，这个举个例子，比如说咱们公司里经常tb是吧（就是团建），然后一般会有个tb主席（就是负责组织团建的那个人）。 tb，team building，团建 第一个阶段，一般tb主席会提前一周问一下团队里的每个人，说，大家伙，下周六我们去滑雪+烧烤，去 阅读全文
摘要：
session是啥？浏览器有个cookie，在一段时间内这个cookie都存在，然后每次发请求过来都带上一个特殊的jsessionid cookie，就根据这个东西，在服务端可以维护一个对应的session域，里面可以放点儿数据。 一般只要你没关掉浏览器，cookie还在，那么对应的那个sessio 阅读全文
摘要：
（1）redis分布式锁 官方叫做RedLock算法，是redis官方支持的分布式锁算法。 这个分布式锁有3个重要的考量点，互斥（只能有一个客户端获取锁），不能死锁，容错（大部分redis节点或者这个锁就可以加可以释放） 第一个最普通的实现方式，如果就是在redis里创建一个key算加锁 SET m 阅读全文
摘要：
大致来说，zk的使用场景如下，我就举几个简单的，大家能说几个就好了： （1）分布式协调：这个其实是zk很经典的一个用法，简单来说，就好比，你A系统发送个请求到mq，然后B消息消费之后处理了。那A系统如何知道B系统的处理结果？用zk就可以实现分布式系统之间的协调工作。A系统发送请求之后可以在zk上对某 阅读全文
摘要：
其实一般问到你这问题，你起码不能认怂，因为既然咱们这个课程是短期的面试突击训练课程，那我不可能给你深入讲解什么kafka源码剖析，dubbo源码剖析，何况我就算讲了，你要真的消化理解和吸收，起码个把月以后了。 所以我给大家一个建议，遇到这类问题，起码从你了解的类似框架的原理入手，自己说说参照dubb 阅读全文
摘要：
首先，一般来说，我个人给你的建议是，你们从业务逻辑上最好设计的这个系统不需要这种顺序性的保证，因为一旦引入顺序性保障，会导致系统复杂度上升，而且会带来效率低下，热点数据压力过大，等问题。 下面我给个我们用过的方案吧，简单来说，首先你得用dubbo的一致性hash负载均衡策略，将比如某一个订单id对应 阅读全文
摘要：
这个不是技术问题，这个没有通用的一个方法，这个是结合业务来看应该如何保证幂等性的，你的经验。 所谓幂等性，就是说一个接口，多次发起同一个请求，你这个接口得保证结果是准确的，比如不能多扣款，不能多插入一条数据，不能将统计值多加了1。这就是幂等性，不给大家来学术性词语了。 其实保证幂等性主要是三点： （ 阅读全文
摘要：
spi，简单来说，就是service provider interface，说白了是什么意思呢，比如你有个接口，现在这个接口有3个实现类，那么在系统运行的时候对这个接口到底选择哪个实现类呢？这就需要spi了，需要根据指定的配置或者是默认的配置，去找到对应的实现类加载进来，然后用这个实现类的实例对象。 阅读全文
摘要：
（1）服务治理 1）调用链路自动生成 一个大型的分布式系统，或者说是用现在流行的微服务架构来说吧，分布式系统由大量的服务组成。那么这些服务之间互相是如何调用的？调用链路是啥？说实话，几乎到后面没人搞的清楚了，因为服务实在太多了，可能几百个甚至几千个服务。 那就需要基于dubbo做的分布式系统中，对各 阅读全文
摘要：
（1）dubbo负载均衡策略 1）random loadbalance 默认情况下，dubbo是random load balance随机调用实现负载均衡，可以对provider不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。 2）roundrobin 阅读全文
摘要：
（1）dubbo支持不同的通信协议 1）dubbo协议 dubbo://192.168.0.1:20188 默认就是走dubbo协议的，单一长连接，NIO异步通信，基于hessian作为序列化协议 适用的场景就是：传输数据量很小（每次请求在100kb以内），但是并发量很高 为了要支持高并发场景，一般 阅读全文
摘要：
（1）为什么要将系统进行拆分？ 网上查查，答案极度零散和复杂，很琐碎，原因一大坨。但是我这里给大家直观的感受： 1）要是不拆分，一个大系统几十万行代码，20个人维护一份代码，简直是悲剧啊。代码经常改着改着就冲突了，各种代码冲突和合并要处理，非常耗费时间；经常我改动了我的代码，你调用了我，导致你的代码 阅读全文