0 初衷
如今有不少的技术交流群，不少的群都是这样的：mysql
- 1 常常扯淡
- 2 不少伸手党
- 3 一些道听途说的结论都拿来做为本身的观点
- 4 技术交流的深度不够
花费了不少时间在群上，可是收获缺并很少。而想找到一个有深度的交流群，而不是一个问答群。但愿以下：程序员
- 1 针对一个话题，感兴趣的人都可以进行深刻研究后，而后再在一块儿相互探讨
- 2 有不少处于相同阶段的志同道合的伙伴，你们都很是上进
而我就是这样的一个处在初级阶段的一我的，最近也在迷茫，该怎么去发展，想找同龄人一块儿交流。下面先简单谈谈我最近的粗浅感觉，与君共勉web
1 感觉
1.1 深度和广度
有的人会告诉你要专注一点，不要什么都学。有时候你本身却是想多补充补充广度，造成一个知识体系。redis
深度和广度其实有时候很难把控，可能你所谓的深度根本就不深。算法
我这个小白目前的想法是：sql
-
广度：初始阶段，扩展扩展广度。如中间件、数据库、分布式领域。数据库
-
基本的数据结构和算法，JDK集合源码，多线程（锁、线程池）数据结构
-
web:SpringMVC、Spring事务体系、mybatis或hibernate、数据库链接池mybatis
-
通讯：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 打好基础
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
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