• Hadoop的RPC设计分析

    本文出自:【InTheWorld的博客】 (欢迎留言、交流)

    之前鼓捣Hbase的时候,觉得单机和伪分布式模式太low了,就在笔记本上用三个虚拟机搭建了一个“完全分布式”的Hbase环境(心疼破本子一秒钟)。刚好趁这个元旦假期,我就研究了一下Hadoop。

    Hadoop也算是个巨无霸了,涉及了很多方面的功能。个人工作中有多个RPC client管理以及交互的场景,一直觉得设计的不太好。所以心里一直想研究一下优秀项目的多路RPC是如何实现的,然后计划一直搁置到现在。难得小假期,就拿手上的Hadoop开刀吧!

    1. 宏观背景

    hadoop-hdfs-architecture

    Hadoop的RPC确实挺复杂的,就单单以HDFS为例,client与NameNode, client与DataNode, NameNode与DataNode以及DataNode与其他DataNode。如果要提到Hadoop map/reduce,那么事情就更不简单了。虽然Hadoop的RPC如此复杂,但是这些RPC都是基于同一个RPC框架,这个RPC框【查看更多】

  • Raft算法实现之状态存储——基于etcd

    本文出自:【InTheWorld的博客】 (欢迎留言、交流)

    Paxos算法也许是最著名的分布式一致性算法,而Raft则大概是最流行的分布式一致性算法。由于经验和水平所限,单纯看论文感觉并不能达到更进一步的理解。前面听闻Kubernetes, Docker Swarm,  CockroachDB等等牛逼的项目都在用Raft。毕竟是经过大规模生产环境考验的技术,我觉得很有必要学习一下。而且etcd的Raft实现是开源的,毕竟“源码之前,了无秘密”。

    image

    无论是Paxos还是Raft,它们都是致力于维护一个RSM(Replicated State Machine),如上图所示。对于RSM来说,状态存储是非常关键的。在这篇博客里,我准备基于etcd的实现分析一下Raft的状态存储。Raft状态的存储主要靠Snapshot和WAL(write ahead log)实现。

    • 和很多数据库一样,为了保证数据的安全性(crash或者宕机下的恢复)
    【查看更多】
  • word2vec学习笔记——CS224n

    CS224n是斯坦福大学的一门关于自然语言处理的公开课。课程的第二讲的主要内容就是word2vec。word2vec是Google在2013年发布的一门自然语言处理技术。

    词向量一般有两种形式,一种叫做One-hot表示,另外一种叫做Distributed Representation。word2vec就属于第二类。word2vec这种词向量表示方法,可以通过计算欧式距离等来判断它们之间的相似度。word2vec本质上属于一种神经网络语言模型范畴的技术,这一点和n-gram、决策树等等这些统计语言模型还是有不少区别的。

    1. Log-Linear模型

    Log-linear模型算是word2vec的一大基础了。虽然我现在也没深刻理解Log-linear的科学性论证,但是如果接受它这个模型,去理解word2vec,还是相对比较直观的。模型的具体内容如下:

    1. 一个输入集合X;
    2. 一个
    【查看更多】
  • 图片加载库Glide的“经验型”用法

    本文出自:【InTheWorld的博客】 (欢迎留言、交流)

    Glide算是Android开发中比较常见的一个开源库了,它使用起来非常简单。说实话,图片加载我基本只用了Glide,因为我的许多看似复杂的需求,在Glide的框架下都能比较轻松的实现。因此,我根本没有心思去趟其他的坑,而且在实现的过程中也发现,Glide的设计是非常棒的,简单的API、很强的扩展性都让我非常满意。

    写这篇blog的出发点不是Glide的基本教学,而是总结本人的经验性用法。因此,本文的逻辑和结构都会比较松散,还望看官海涵。

    1. 自定义ModelLoader

    在有些情况下,我们需要自定义ModelLoader,即模型加载器。这个ModelLoader的输入是图片资源的标识,输出则是一个InputStream。Glide则可【查看更多】

  • 高并发分布式系统唯一ID生成

    了解Paxos算法的同学应该知道,Paxos算法要求Proposal ID全局唯一(且递增)。而事实上,全局唯一ID(且递增)的生成本身是需要一些技术来保证的。生成全局唯一ID的方法其实有很多,但是满足高QPS、高可用以及低延迟这些要求其实并不简单。作为一个并没有机会参与高并发系统的菜鸟,我也只能通过大厂的分享来理解和学习了。开门见山的说,本文的内容就是总结三个大型公司的生产环境的唯一ID生成方案,对于不满足条件(高QPS、高可用以及低延迟)的方法这里就先略过了。此外,可能还有很多其他先进的方法,但是碍于我知识量有限并不知道。

    1. Twitter的snowflake算法

    snowflake算法其实是一种比较简单而常见的唯一ID生成算法。MongoDB内部的ID生成算法就和sno… 【查看更多】

  • 《SRE Google运维解密》读书笔记(部分)

    我之所以了解到这本书,是因为前面看Kubenetes的时候,作者提到Google使用的Borg集群管理系统。据称,Google在05年之前就开始使用Borg集群管理系统。对于这一点,我其实有些惊讶的。毕竟服务器集群编排系统其实也就是最近几年才逐渐兴起的。然后我查相关资料的时候,发现了这本书。草草翻阅了一下目录,发现这本书其实是属于DevOps的书籍。

    最近几年,后端出了很多新鲜的名词,比如微服务(micro service),DevOps,Docker容器,容器编排等等。看起来好像是五花八门,但事实上都是多位一体的。关键原因是互联网服务的规模增长和标准提高,分布式后端系统不断普及。在分布式后端系统中,micro service是一种科学的架构,按照服务拆分完成分布式的架构模型。而分布式系统本身的复杂度是很高的,传统的运维方式难以保证业务的稳定,而DevOps就是为了改善这种【查看更多】

  • 再学Paxos算法

    本文出自:【InTheWorld的博客】 (欢迎留言、交流)

    Paxos算法应该是最著名的分布式一致性算法之一了。然而说起来令人汗颜,我对Paxos的算法的理解一直都是糊里糊涂的。国庆假期在看《SRE Google运维解密》,“分布式共识系统”(也就是Chubby)章节,也在强调Paxos算法。正好趁着这个机会,好好学习总结一下。

    Paxos算法可以分为Basic Paxos和Multi-Paxos两种形式,它们的主要特点如下,为了对比起见,这里把它们列在一起了:

    ● Basic Paxos (“single decree”): 

    • 一个或者多个服务器发起提议 
    • 系统会在一个被选择的提议值上达成一致
    • 只有一个提议值会被选择

    ● Multi-Paxos: 

    • Multi-Paxos通过多回合的Basic Paxos算法在一列的值上形成一致,这一系列值相当于redo log,它的一致性
    【查看更多】
  • 《Docker源码分析》笔记

    最近几天的时间都在看《Docker源码分析》,买书的时候是觉得需要补补Docker原理方面的知识。因为过多的Docker书籍都偏向于使用,究其原因是Docker本身的工具属性很强。到目前为止,看完了全书大约70%的内容,关于镜像下载和管理部分的内容暂时略过了。

    • 负面评价:

    我对本书的整体评价不高,好在本来的期望值也不高。在我看来,这本书主要的问题在于本末倒置。cgroup和namespace作为Docker的基础技术,本书基本没怎么分析和介绍,甚至整个libcontainer都没有花多少篇幅。此外,UnionFS之类的文件系统也算是Docker作为虚拟化产品的一大特色,依然是寥寥数笔就带过了。

    • 正面评价:

    正如前文所说,Docker是一个工具性的产品,易用性是它的基本属性。当然这也导致了很少有用户去深入研究Docker实现方面的东西。像我这样好奇心… 【查看更多】

  • Innodb存储引擎中锁的简析

    mariadb

    基本概念

    innodb是MySQL/MariaDB的默认存储引擎,也是最广泛使用的存储引擎。几年前研究MySQL实现的时候,也看过一本关于innodb的书,但是理解并不到位。最近计划补充一下存储方面的知识,这里就从innodb入手研究一下。对于一个五级数据库引擎(实现事务功能),锁的设计是非常重要的,这篇博客的主题也就是学习innodb中锁。

    innodb中有不少锁,这篇blog主要研究一下几个点,前两点是锁的模式,后两个知识点是锁的类型。这里我想强调一下,锁的模式和锁的类型是两个概念,千万不要搞混了。很多资料上,包括MySQL的官方文档上,都把这些知识点混在一起,给我带来了不少困惑。

    • Shared and Exclusive Locks:共享锁和互斥锁
    • Intention Locks:意向锁

    两种类型的锁:

    • Record Locks
    • Gap Locks

    1. Shared and Exclusive
    【查看更多】
  • 初步学习分布式数据库

    写本文的初衷是由于最近在看《大规模分布式存储系统》,期间有不少疑问以及一些新的认识。这里就准备把自己的疑问和认识记录一下,供以后回炉知识点。这里行文的逻辑大致是以不同的数据库产品或者技术展开,可能会显得比较乱。而且,就目前来说,我对各种分布式数据库的理解都还很肤浅,本文权当自娱自乐了,摘抄很多。

    1. Hbase/BigTable

    作者在书中把Hbase定义为分布式表格系统,其实也没有什么毛病。Hbase的事务支持相当有限,只支持行级事务。Hbase的系统架构图如下:

    Hbase

    Client:包含访问HBase的接口,并维护cache来加快对HBase的访问,比如region的位置信息

    Master:为Region server分配region,负责Region server的负载均衡,发现失效的Region server并重新分配其上的region,管理用户对table的增删改查操作

    Region【查看更多】