0 初衷

现在有很多的技术交流群，很多的群都是这样的：

• 1 经常扯淡
• 2 很多伸手党
• 3 一些道听途说的结论都拿来作为自己的观点
• 4 技术交流的深度不够

花费了很多时间在群上，但是收获缺并不多。而想找到一个有深度的交流群，而不是一个问答群。希望如下：

• 1 针对一个话题，感兴趣的人都能够进行深入研究后，然后再在一起相互探讨
• 2 有很多处于相同阶段的志同道合的伙伴，大家都非常上进

而我就是这样的一个处在初级阶段的一个人，最近也在迷茫，该怎么去发展，想找同龄人一起交流。下面先简单谈谈我最近的粗浅感受，与君共勉

1 感受

1.1 深度和广度

有的人会告诉你要专一一点，不要什么都学。有时候你自己倒是想多补充补充广度，形成一个知识体系。

深度和广度其实有时候很难把控，可能你所谓的深度根本就不深。

我这个小白目前的想法是：

• 广度：初始阶段，扩展扩展广度。如中间件、数据库、分布式领域。

  • 基本的数据结构和算法，JDK集合源码，多线程（锁、线程池）
  • web:SpringMVC、Spring事务体系、mybatis或hibernate、数据库连接池
  • 通信：TCP/IP，NIO框架Netty、thrift，RPC中的dubbo
  • 消息队列：kafka、RocketMQ等

  • 调度：

    • 中间件形式的：quartz集群方案、elastic-job（它的Elastic-Job-Cloud也提供资源调度）

    • 大数据方向的调度：

      • oozie、zeus：把不同类型的调度job代码封装起来然后和大数据组件进行交互，用户只需写配置即可
      • 大数据组件内部的调度，又会细划分为资源调度(yarn)和任务调度(AppMaster)
  • KV存储：redis、memcached
  • 关系型数据库如mysql的基本原理，sql引擎、事务（隔离级别、锁、MVCC）、binlog redo undo log、主从复制原理、高可用方案
  • 分布式一致性：paxos、Raft、ZAB。ZooKeeper、etcd

  • 分布式存储：

    • NOSQL：redis的cluster、codis方案，HBase
    • NewSQL:Spanner、CockroachDB、TiDB、OceanBase等。

    上述众多分布式存储的共性部分可以简单概括为2个方面：

    • 1 分片：hash分片如codis、Range分片如HBase、CockroachDB，又如消息队列这类存储天生具有良好的可分片特性（topic和partition）。还有分片这类meta信息的高可用存储，分片的调度（如分片的迁移或者分片的拆分）。如kafka通过leader选举选出一个Controller来管理meta信息（由于meta信息少，所以通过Controller的调度使得每个KafkaServer都存储了一份）和分片的调度。
    • 2 分片的一致性和高可用：倾向于使用paxos、raft来实现分片的同步。如CockroachDB、TiDB使用raft，Spanner、OceanBase使用paxos。

  • 分布式事务：

    • 中间件层面：X/Open DTP模型（不仅与数据库对接还可以与其他实现XA协议的RM对接）、JTA，常采用2PC来实现，如ByteTCC框架
    • 分布式存储层面：如google的Percolator分布式事务方案，小米的Themis（为HBase添加分布式事务支持）也是基于Percolator。很多都是2PC并且进行优化的方案。

    提到了分布式事务又不得不说分布式时序问题：

    • google的TrueTime
    • CockroachDB的HLC
    • 授时服务
  • 分布式计算:MapReduce、Spark等等

  几年内把这些东西的原理以及其中存在的缺陷搞清楚（根据自己的方向，有些深入理解，有些会用即可，有些可能涉及不到，有些漏掉，毕竟方向太多了）。能够融汇贯通，能够看到一些共性的东西，而不再把他们当做一个个孤立的软件来看待。很多设计都是相通的，很多问题是各个软件都会遇到的，如果你能总结出来，那么理解就会更加深入了。

  这个时间因人而异，勤奋和懒惰的差距当然很大。

  这个阶段还没到深入的地步，比如paxos论文你看懂了，但是真实落地到实际的生产系统又是一层挑战。比如你能看懂dubbo，不一定能自己写出来。

  这个阶段同时要加强自己的代码能力，为下个阶段做准备。

• 深度：深入阶段，找到自己的感兴趣的方向，深入做下去，去面临现实中的各种挑战，去做出创新，如

  • 消息队列，加入大厂的消息队列团队，真正去做出一个开源产品来
  • NOSQL：如深入搞HBase，成为committer啥的
  • 分布式KV、分布式数据库

  这个阶段当然需要专注在某个领域内，需要一定时间的积淀（当然我也没啥话语权，还没到这个阶段，只能这么粗略的认为）。

1.2 眼界

特别是我们这种普通程序员，如果局限在自己狭窄的范围，你可能放松对自己的要求。

比如学习ZooKeeper：

• 有些人就会用用
• 有些人看些文章了解其中的原理，自己咀嚼别人的知识
• 有些人看看源码，自己主动获取知识，但处于一知半解的状态
• 有些人源码看的更加深入一些，真正理解背后的设计，背后所面临的一致性问题
• 有些人不仅仅局限于ZooKeeper，开始扩展到其他系统，也能解决其中的不足，有条件的话自己也能造轮子

所以提高自己对知识的要求，你做的还远远不足。

1.3 打好基础

• 学好英语

  需要看国外大师的一些博客文章、各种paper。所以学好英语是必须过的一关。
  

• 学好数据结构和算法

  很多时候都会提出我们做web开发的需要学这些吗？正是因为你不会，才只能做这个。
  

1.4 多总结

举例如下：

• 当你面对redis的全量和增量同步中存在的问题时，你是否曾想其他软件是否也存在这个问题，他们又是怎么解决的？多去了解了解，做到融汇贯通
• 看文章：现在的文章真的太多太多了，这就导致了我们很多时候仅仅是粗浅的浏览了下，并没有去深入其中的细节（可能作者对于每一处都很认真的推敲，可能作者也是不负责任的写一写，这个需要你自己去辨别）。现在很多文章都没有高质量的评论交流可以从侧面看出，现在大家的阅读一般都很粗浅。

2 想做的事

2.1 愿景

想笼络想奋进的人进群，群人数保持在30到50人。

• 每周至少开展1个话题，由话题提出者主导研究，其他人感兴趣的参与研究，然后在某个固定时间大家一起交流。多个话题可以同时展开，各自参加各自的话题小分队
• 基本不允许提简单的问题，这种一般自行解决，最好提一些有质量的话题。这里是一个交流的平台，而不是一个问答平台。
• 长时间不参与各种话题只能劝退出群了，等你有空研究再参与进来
• 各种弄虚作假者来蹭的也会劝退

2.2 要求条件

• 想成大牛的潜力股，具有自我驱动力，能自主去研究一些东西
• 读源码是最最最基本的要求
• 对技术有自己独到的见解和认识
• 乐于分享技术（有自己的技术博客最好，并且要求博客内容质量高）
• 大牛也可以进来指导指导（哈哈）

满足条件的可以先看下下面的测试题，挑选其中3个回答，然后私信留言，核对后拉进群，一起讨论学习。

不满足条件的不要怪别人不给机会，只有自己先变得上进起来，别人自然会去主动找你。

2.3 预先的测试题

• 1 Guava RateLimter中预热是怎么一回事
• 2 你觉得RedLock有没有问题？如果有指出来
• 3 分布式一致性算法中，选举出新的leader后，Raft和ZAB是如何处理上一个leader残留的还未提交的事务的
• 4 如何改进kafka的日志丢失问题

3 话题内容

这里准备把一些话题列出来，仅供参考，大牛就不要拍砖了。

3.1 分布式锁话题

• 有哪些方案？
• 方案都有哪些缺陷，你对RedLock怎么看？
• 从各种方案中你能总结出如何来设计分布式锁？有哪些要点？

3.2 红黑树

• 如何看待算法导论中红黑树的相关操作的解法
• 你是否能直接描述出如何插入删除数据的过程

3.3 恢复技术以及副本同步（增量和全量同步）

• redis的rgb和aof
• ZooKeeper的快照和事务日志
• hdfs的image和editLog
• kafka？
• mysql？

上述几种都会面临如何恢复，以及如何进行副本同步。

这些过程中有哪些技术难点？他们分别是怎么应对的？

你能总结出来什么东西？

3.4 paxos

• 1 paxos的针对场景的误解：

  • 达成一个建议的场景
  • 日志复制场景
• 2 paxos的运行过程
• 3 paxos的证明过程
• 4 base paxos与ZAB和Raft的区别

  如多写入还是单写入

• 5 base paxos和multi-paxos
• 6 使用多轮的base paxos来进行日志同步，见使用Basic-Paxos协议的日志同步与恢复
• 7 使用Multi-Paxos协议的日志同步使用Multi-Paxos协议的日志同步与恢复
• 8 对于上述7文章中的幽灵复现问题的讨论

3.5 undo redo binlog

• 1 undo redo 都可以实现持久化，他们的流程是什么？为什么选用redo来做持久化？
• 2 undo、redo结合起来实现原子性和持久化，为什么undo log要先于redo log持久化？
• 3 undo为什么要依赖redo？
• 4 日志内容可以是物理日志，也可以是逻辑日志？他们各自的优点和缺点是？
• 5 redo log最终采用的是物理日志加逻辑日志，物理到page，page内逻辑。还存在什么问题？怎么解决？Double Write
• 6 undo log为什么不采用物理日志而采用逻辑日志？
• 7 为什么要引入Checkpoint？
• 8 引入Checkpoint后为了保证一致性需要阻塞用户操作一段时间，怎么解决这个问题？（这个问题还是很有普遍性的，redis、ZooKeeper都有类似的情况以及不同的应对策略）又有了同步Checkpoint和异步Checkpoint
• 9 开启binlog的情况下，事务内部2PC的一般过程（含有2次持久化，redo log和binlog的持久化）
• 10 解释上述过程，为什么binlog的持久化要在redo log之后，在存储引擎commit之前？
• 11 为什么要保持事务之间写入binlog和执行存储引擎commit操作的顺序性？（即先写入binlog日志的事务一定先commit）
• 12 为了保证上述顺序性，之前的办法是加锁prepare_commit_mutex，但是这极大的降低了事务的效率，怎么来实现binlog的group commit？
• 13 怎么将redo log的持久化也实现group commit？至此事务内部2PC的过程，2次持久化的操作都可以group commit了，极大提高了效率

3.6 AQS

• 1 AQS中一旦某个线程1获取到了锁正在执行同步代码块，这时候其他线程再来获取锁，他们会不断的CAS尝试获取锁一段时间之后再被阻塞还是立马被阻塞呢？

  这个问题要综合的考虑，既有AQS的问题又有AQS对外留出的tryAcquire方法的问题