前言

在上一篇的RPC实现，使用了Socket来进行通信，这种方式的缺点很明显，Socket的IO是同步阻塞的，即你的线程会一直等到有服务进来或者read()有消息。这时候有其他线程想要链接，为了不被阻塞，只能再开一个线程去处理。

虽然可以通过线程池来复用线程，但是通信线程多起来还是会影响到整个服务的性能。所以这篇我们将使用NIO来代替BIO来实现服务之间的通信。代码上传至github，链接。

前言

RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。直白点说它可以让你调用远程接口，就像调用本地方法一样，要实现这个简易版功能要用到socket编程、JDK动态代理、反射等。

dubbo就是阿里实现的RPC微服务的一种框架了，这篇记录一下自己的第一版RPC框架。代码上传至github,链接

前言

常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。

所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务。

例如，一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。

一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。

前言

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

这篇我来说明一下三者为什么不可兼得，以及Zookeeper在AC之间的取舍。

前言

在前面两篇的博客中，Zookeeper提供的功能包括：配置共享、命名服务、分布式同步、服务注册等。设想一下如果存放Zookeeper服务的机器宕机了，那这些功能不就没得用了嘛！

所以Zookeeper需要维护一个集群，就算一个机器宕机了，还有其他的可以替上。随之而然解决集群中的数据一致性就成为了Zookeeper集群的首要问题。Zookeeper中使用了Zab协议来保证各个ZK之间的同步。

Zab协议有两种模式，崩溃恢复模式和消息广播模式。其中崩溃恢复模式是在服务启动或者leader宕机的时候，原来选举出leader。消息广播模式用来保持各个副本之间的数据一致性。总结就是一句话，崩溃恢复模式来保证服务的高可用性，消息广播模式保持节点之间的数据一致性。

前言

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置共享、命名服务、分布式同步、服务注册等。

上一篇博客中我们了解到Zookeeper可以用来实现分布式同步，主要是利用了顺序临时节点和watcher的机制来实现的，所以今天再来讲一下Zookeeper在其他场景上的应用。

前言

在上一篇博客中，我们可以用redis来实现分布式锁，但是仔细观察下面的伪代码，你会发现redis的竞争锁的机制太低效了，因为我们是通过自旋的方式去获得锁，而且实现比较复杂，需要考虑原子性、误删的问题。所以这篇我将介绍如何使用Zookeeper来实现分布式锁。

1
2
3
4
5
6

String threadId = Thread.currentThread().getId()
while(true){//通过自旋的方式去竞争锁，低效浪费cpu
	if (jredis.set(key,threadId,30,nx)==1)
		break;
}
逻辑处理...

前言

我们知道在多线程中，有时候为了保证一个代码块只被一个线程执行，从而通过加锁的方式实现，如Java中的synchronized语法。这可以保证一个进程不同线程的同步，那分布式集群中又是如何来保证线程间的同步呢?

状态：
距离上一篇博客已经有一个月了，这说明最近的学习状态的确不够理想。在休息之前，一直告诉自己，乘着放松的时间把状态调整好，现在是休息好了，但是状态却找不回来。老师交代的论文也没怎么看，说实话我觉得论文这块不是我的菜，看多了反而觉得烦。

值得庆幸的是，学习的步伐始终没有停下来，每天早上会去看公总号推荐的技术性文章，这是一个好习惯，希望保持住。不论学习的效率问题，至少我对这个行业的初心还是保持不变，我也相信这会是我学习路上最好的老师。

新get的知识：
在前面一个月，由一篇关于分布式锁的博客，学到了如何利用redis来实现分布式锁，认识到zookeeper在实现分布式锁上更加具有优势，这些在后面的博客会记录下来。

架构方面：
这两天在看service mesh，有点楞，还体会不到这个微服务网格的好处在哪，记得上次师兄们在群里聊到蚂蚁有自己的一套SOFA MESh，当时是完全不知道他们在讲什么，至少现在我知道了，说明我也在进步。
在这一个月里，微服务的RPC的框架有了一定的了解，也写了一个demo，后面会针对Dubbo实现的demo来解释加深对RPC的认识。

展望：
把前面的提到知识点梳理好，相应的博客也要接着写掉。然后抓紧把实验做了，其实要自己实现word2vec是没什么难度的，但是总觉得和自己前进的方向没有什么重合点，以至于我不想动。架构学习上多参加开源社区，增加知识面的广度，当然还是要有自己的一个擅长的领域。

前言

前阵子在知乎上看到一条：作为程序猿，你的老板提出过哪些无理的需求。 在下面的回答看到一条说： 老板要他一个人完成一个类似知乎的推荐系统。下面的评论多数是在调侃老板的无理的需求，还有的人说直接给一个随机值就好了，哈哈哈。

其实推荐系统实现是不难，网上有很多完成好了的轮子，我们只要知道如何去使用即可。这篇我来记录一下，实验室项目中的推荐功能和实现方式。功能大体是，用户填写自己的需求，然后系统推荐出和这个需求最相关的专家以及论文等成果。