沈鸿斌的博客

工作中使用了微服务架构，接下来的一段时间里，我会写一系列的文章来介绍微服务架构，这篇文章主要讲述了微服务架构中的数据管理。

定义和理解Linearizability是常用的一致性模型（对于一致性模型，笔者后续会有专门的文章来讨论）之一，Linearizability也可以被称为原子一致性（atomic consistency），强一致性（strong consistency），立即一致性（immediate consistency）或外部一致性（external consistency ）。很难给Lineari...

在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第六篇文章， 主要讲述了RPC中负载均衡这一块的内容。常见的LB策略常见的LB策略有很多：RoundRobin (RR)： 一个列表中轮着来WeightedRoundRobin (WRR)： 带权重的RRLocalFirst：本地服务优先Random：随机选择ConsistentHash： 一致性哈希这些策

在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架（我已经实现了一个示例框架， 代码在我的github上）。 这是系列第五篇文章， 主要讲述了服务器端的实现。在前面的几篇文章里， 我们已经实现了客户端创建proxy bean， 并利用它来发送请求、处理返回的全部流程： 扫描package找出需要代理的service通过服务注册中心和Load Balancer获取se

在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第四篇文章， 主要讲述了客户端和服务器之间的网络通信问题。模型定义我们需要自己来定义RPC通信所传递的内容的模型， 也就是RPCRequest和RPCResponse。@Data@Builderpublic class RPCRequest { private String requestId; pr

在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第三篇文章， 主要讲述了服务注册和服务发现这一块。在系列的第一篇文章中提到，我们的RPC框架需要有一个服务注册中心。 通过这个中心，服务可以把自己的信息注册进来，也可以获取到别的服务的信息（例如ip、端口、版本信息等）。这一块有个统一的名称，叫服务发现。对于服务发现，现在有很多可供选择的工具，例如zookeeper, et

在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第二篇文章， 主要讲述了如何利用Spring以及Java的动态代理简化调用别的服务的代码。在本系列第一篇文章中，我们说到了RPC框架需要关注的第一个点，通过创建代理的方式来简化服务调用代码。如果不使用代理？如果我们不用代理去帮我们操心那些服务寻址、网络通信的问题，我们的代码会怎样？ 我们每调用一次远端服务，就要在业务代码中

开始造轮子之旅， 本期轮子：RPC框架。 在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第一篇文章， 主要从整体角度讲述了一个RPC框架组成结构与关注点， 并且附上了我的RPC框架的实现作为参考。RPC框架的关注点首先，什么是RPC？RPC的全称是Remote Procedure Call，远程过程调用。RPC框架有很多，比如hsf、dubbo等等。借助RPC框

从这一章开始，我们就正式从单机应用转向了分布式应用的旅程！ ps: 其实DDIA这书我1月份已经看完了，只不过那会儿实在没有心力去翻译。前段时间太太太忙了，对几千万日活的系统做了技术栈迁移、跨洲数据中心无缝平移。后续也会写文章来分享我们是怎么做的，欢迎持续关注。副本机制的意思是，在多台通过网络互连的机器上保存同一份数据的多份拷贝。我们为什么需要副本：让用户在地理上离数据...

这一章我们会讨论分布式系统中一些常见的问题，在下一章中我们会讨论这些问题的解决办法。1.故障与部分失败在分布式系统中，系统的部分组件常常会以以某种未知的方式被破坏，我们称之为部分失败/部分故障。而我们的目标就是在不可靠的组件上构建一个可靠的系统。为了容忍部分失败：第一步是检测失败：大多数系统利用超时来判断节点是否可用，但是超时机制没办法区分是网络失效还是节点宕机在检...

工作中用到了Consul来做服务发现，之后一段时间里，我会陆续发一些文章来讲述Consul实现原理。在前一篇文章中，我介绍了Raft算法。这篇文章会讲讲Consul是如何使用Raft算法来实现分布式一致性的。Consul中的Raft只有以server模式运行的Consul节点，才会被认为是Raft节点集的一部分。所有的client节点会把收到的请求转发到server节点中。这么设计的原因主要是出于

最近工作中用到了Consul，在学习过程中，发现它是基于Raft来做分布式一致性的。正巧以前学习过Raft, 那么就正好借此机会复习一下吧！

工作中用到了Consul来做服务发现，之后一段时间里，我会陆续发一些文章来讲述Consul实现原理。在前几篇文章介绍完了Consul用到的两个关键性东西Raft和Gossip之后，这篇文章会讲述Consul的整体架构。本文基于一篇别的译文，并做了一些改进和完善。术语表代理(agent)： 代理是Consul集群上每个成员的守护进程，它是由consul agent开始运行。代理能够以客户端或服务

工作中用到了Consul来做服务发现，之后一段时间里，我会陆续发一些文章来讲述Consul实现原理。这篇文章会讲述Consul是如何使用Gossip来做集群成员管理和消息广播的。Consul使用Gossip协议来管理集群中的成员关系，以及把消息广播到集群中。而这些Gossip的特性是利用Serf这个lib来实现的。下面，我们先来看看什么是Gossip协议。Gossip协议 在学习Gossip的

这篇文章大致讲解了用Nginx+Tomcat+Spring+Redis实现分布式session。Spring项目地址：https://github.com/hshenCode/spring_redis_exercise1. 系统拓扑1台Redis服务器，用来存储session。2台Tomcat服务器，访问Redis进行session存储。1台Nginx服务器，作为反向代

工作的项目中使用了消息队列，需要注意几个关键问题：消息的顺序问题消息的重复问题事务消息看了一篇不错的文章，以下是那篇文章部分内容：一、顺序消息消息有序指的是可以按照消息的发送顺序来消费。例如：一笔订单产生了 3 条消息，分别是订单创建、订单付款、订单完成。消费时，要按照顺序依次消费才有意义。与此同时多笔订单之间又是可以并行

1.Google文件系统（GFS）使用一堆廉价的商用计算机支撑大规模数据处理。GFSClient： 应用程序的访问接口Master（主控服务器）：管理节点，在逻辑上只有一个（还有一台“影子服务器“，在主控服务器失效时提供元数据，但并不是完整的热备服务器），保存系统的元数据，负责整个文件系统的管理。Chunk Server（数据库服务器）：负责具体的存

这几年微服务大行其道，随之而来也伴随着很多问题： 服务注册和发现（常见解决方案如Consul, ZK, etcd)熔断和降级 （如Hystrix)…在服务过载时， 一个常见的解决方案是熔断。以前的熔断方案基本都是各个服务独自处理的， 即如果一个服务无法处理所有的请求， 那么就抛弃一部分请求。这种粗暴的处理方式并不能缓解整个系统的负载， 并且浪费了很多计算资源，比如以下场景：假设...