招募有志青年
招募有志青年
乒乓狂魔 发表于1年前
招募有志青年
  • 发表于 1年前
  • 阅读 1708
  • 收藏 17
  • 点赞 12
  • 评论 10

移动开发云端新模式探索实践 >>>   

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

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方法的问题

  • 打赏
  • 点赞
  • 收藏
  • 分享
共有 人打赏支持
粉丝 959
博文 105
码字总数 271356
评论 (10)
yangqq
前排菜鸡围观下
-悟空-
可以啊 怎么加入?
LCZ777
怎么加入呢?
乒乓狂魔
怎么加入,文中都已经说了
helloworlda
建议:楼主把 “招募” 改为 “寻找” 更亲切
乒乓狂魔

引用来自“helloworlda”的评论

建议:楼主把 “招募” 改为 “寻找” 更亲切
嗯,用词不当,可能大家也不会在意
杰森.金
望其项背,继续修炼
110hxl
菜鸟前来膜拜:bowtie:
苏吹风
那4个问题也太深了点吧,算了,还是先打怪升级
九州暮云
今天发现贵博客,会认真看下去,认真学习
×
乒乓狂魔
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: