沈鸿斌
码龄12年
求更新 关注
提问 私信
  • 博客:680,687
    680,687
    总访问量
  • 123
    原创
  • 560
    粉丝
  • 2
    关注
IP属地以运营商信息为准,境内显示到省(区、市),境外显示到国家(地区)
IP 属地:上海市
加入CSDN时间: 2013-10-13

个人简介:爱生活,爱Coding

博客简介:

沈鸿斌的博客

查看详细资料
个人成就
  • 获得402次点赞
  • 内容获得164次评论
  • 获得407次收藏
  • 博客总排名2,330,553名
创作历程
  • 2篇
    2019年
  • 11篇
    2018年
  • 40篇
    2017年
  • 41篇
    2016年
  • 67篇
    2015年
成就勋章
TA的专栏
  • JAVA虚拟机
    6篇

TA关注的专栏 1

TA关注的收藏夹 0

TA关注的社区 0

TA参与的活动 0

创作活动更多

王者杯·14天创作挑战营·第2期

这是一个以写作博客为目的的创作活动,旨在鼓励码龄大于4年的博主们挖掘自己的创作潜能,展现自己的写作才华。如果你是一位热爱写作的、想要展现自己创作才华的小伙伴,那么,快来参加吧!我们一起发掘写作的魅力,书写出属于我们的故事。 注: 1、参赛者可以进入活动群进行交流、分享创作心得,互相鼓励与支持(开卷),答疑及活动群请见https://bbs.csdn.net/topics/619735097 2、文章质量分查询:https://www.csdn.net/qc 我们诚挚邀请你们参加为期14天的创作挑战赛!

65人参与 去参加
  • 最近
  • 文章
  • 专栏
  • 代码仓
  • 资源
  • 收藏
  • 关注/订阅/互动
更多
  • 最近

  • 文章

  • 专栏

  • 代码仓

  • 资源

  • 收藏

  • 关注/订阅/互动

  • 社区

  • 帖子

  • 问答

  • 课程

  • 视频

搜索 取消

如何构建高可用的系统(三):服务治理篇

在如何构建高可用的系统(一):Overview中, 我提到了以下几点:系统依赖的一切下游系统都是不可靠的, 它们随时可能出问题系统的上游可能有多个, 而且每个上游的行为都是不可预知的。如果某个上游抽风把我的系统搞崩, 那么就会影响所有的上游高可用是有前提条件的,一个系统对当前的负载能提供高可用, 不代表负载上升之后仍然高可用如果把这几个问题,映射到现在非常流行的“微服务架构”下,就可以...
原创
发布博客 2019.01.19 ·
1363 阅读 ·
3 点赞 ·
2 评论 ·
1 收藏

如何构建高可用的系统(二): 消除单点与自动故障转移

前一篇文章我们讲到, 一切单点都是不可靠的, 如果系统中某个地方可能会出问题(就算概率很低),那么它迟早会出问题。 也就是我们常说的Murphy’s Law。如果要提高系统的可用性, 那么就必须尽可能消灭掉系统中所有的单点,并且在发生故障时,把流量自动转移到运行正常的节点。在这篇文章中, 我会以互联网产品后端常见的架构为例, 讲述如何达到这个目标。1.常见系统架构互联网后端应用的常见架构可...
原创
发布博客 2019.01.12 ·
1615 阅读 ·
1 点赞 ·
0 评论 ·
2 收藏

如何构建高可用的系统(一):Overview

1. What首先,我们需要对"可用性"下一个定义。 业界常用SLA(Service Level Agreement)来描述一个系统的可用性, SLA包含很多信息(服务内容、故障恢复时间、可用性等), 在这里我们笼统的用“N个9”来指代,比如4个9指的是99.99%的可用性、 5个9指的是99.999%的可用性。假如一个系统声称它的年可用性是4个9, 那它提供的可用性承诺
原创
发布博客 2018.12.22 ·
1479 阅读 ·
0 点赞 ·
0 评论 ·
2 收藏

如何构建高可用的系统(一):Overview

1. What首先,我们需要对"可用性"下一个定义。 业界常用SLA(Service Level Agreement)来描述一个系统的可用性, SLA包含很多信息(服务内容、故障恢复时间、可用性等), 在这里我们笼统的用“N个9”来指代,比如4个9指的是99.99%的可用性、 5个9指的是99.999%的可用性。假如一个系统声称它的年可用性是4个9, 那它提供的可用性承诺
原创
发布博客 2018.12.22 ·
1479 阅读 ·
0 点赞 ·
0 评论 ·
2 收藏

全球异地多活架构设计(二): 数据层的支持

要做到全球异地多活, 一定要在数据层支持多机房写入, 并且对大多数业务场景提供最终一致性的解决方案。原因如下:跨洲的网络延迟在100ms的数量级,如果只有单点写, 对于用户体验是种灾难对于高频操作来说, 如果做强一致性,那么任然受限于网络延迟, 对于用户体验是种灾难那么随之而来就有两个问题需要解决:跨机房的数据同步多点写入时的数据冲突处理一 、数据同步数据的同步有几个核心问...
原创
发布博客 2018.12.01 ·
3134 阅读 ·
1 点赞 ·
0 评论 ·
8 收藏

全球异地多活架构设计(一): Why and How

很多全球化的产品, 比如facebook、twitter, 它们的用户遍布世界各地。 工程师们往往会在全球设立多个数据中心(DC)供用户访问, 我们可以称之为异地多活。在后续一段时间里, 我会写一系列的博客,和大家一起探索异地多活架构。这篇文章主要是讨论我们为什么需要异地多活, 以及实现这种架构所需要解决的问题。一、异地多活的好处1. 提高用户体验一个产品最重要的是提供良好的用户体验,这对...
原创
发布博客 2018.11.04 ·
4530 阅读 ·
1 点赞 ·
0 评论 ·
7 收藏

对微信《Scalable Overload Control for Large-scale Microservice Architecture》论文的解读

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

《设计数据密集型应用/DDIA》精要翻译(七) :Linearizability

定义和理解Linearizability是常用的一致性模型(对于一致性模型,笔者后续会有专门的文章来讨论)之一,Linearizability也可以被称为原子一致性(atomic consistency),强一致性(strong consistency),立即一致性(immediate consistency)或外部一致性(external consistency )。很难给Lineari...
翻译
发布博客 2018.04.14 ·
735 阅读 ·
0 点赞 ·
0 评论 ·
0 收藏

《设计数据密集型应用/DDIA》精要翻译(六) :分布式系统中的问题

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

《设计数据密集型应用/DDIA》精要翻译(五) :事务

1. 事务的ACID虽然ACID我们已经说滥了,这里我想再说一下一致性和隔离性。一致性一致性在不同的术语中有不同的含义:在前面那篇博客中,我们讨论了副本之间的一致性(比如最终一致性、读已之写一致性等)在CAP中,一致性表示可线性化(即只要有一个客户端成功写入,别的客户端后续的读取必须能看到刚刚写入的值。 详见本系列第七篇。)在ACID中,指数据库在事务前后保持正确(比如转...
翻译
发布博客 2018.04.05 ·
746 阅读 ·
0 点赞 ·
0 评论 ·
0 收藏

《设计数据密集型应用/DDIA》精要翻译(四) :副本机制

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

《设计数据密集型应用/DDIA》精要翻译(三) :数据的存储和获取之底层数据结构

看了这三章,我最大的收货并不是说学到了什么新的知识,而是对以前通过各种渠道所掌握的知识重新进行了梳理和归纳,使它们有种脉络相通的感觉。一、驱动你的数据库的数据结构这也许是世界上最简单的数据库实现:db_set () { echo "$1,$2" >> database}db_get () { grep "^$1," dat...
翻译
发布博客 2018.01.15 ·
2461 阅读 ·
1 点赞 ·
0 评论 ·
4 收藏

《设计数据密集型应用/DDIA》精要翻译(二) :数据模型和查询语言

当我们在设计kafka、mysql这样的数据密集型应用时,数据模型也许是最为重要的一个考虑点。因为它不仅影响了代码的写法,还影响着我们解决问题的思维方式。这是第一章第二节的读书笔记,介绍了几种不同的数据模型以及数据查询语言。(其实看目录就知道前两章都是小打小闹热热身,但是既然是神书,还是要好好看不是么?)一、关系型模型与文档型模型的比较关系型数据库和文档型数据库有很多的差异...
翻译
发布博客 2018.01.13 ·
1202 阅读 ·
0 点赞 ·
0 评论 ·
0 收藏

《设计数据密集型应用/DDIA》精要翻译(一) :reliability, scalability, maintainability

之前一段时间在看Kafka的源码分析,想学着做个分布式消息系统。后来听说 《设计数据密集型应用》这本书是2017年的神书,对这样的数据系统的内在精髓有很好的讲解。 看完这本书之后再看kafka之类的数据系统能事半功倍。因此,虽然每天忙于搬砖,但还是要抽出时间来拜读一下!这本书暂时还没有中文版,未来的一段时间里我会陆陆续续边看边做部分精华内容的翻译。这是第一章第一节的读书笔记,介绍了re...
翻译
发布博客 2018.01.11 ·
3016 阅读 ·
2 点赞 ·
0 评论 ·
3 收藏

关于负载均衡的一些总结

之前只了解Nginx相关的负载均衡,前段时间写RPC框架的时候涉及到LB这块,就去详细学习了些,在这里做个简单的总结。参考资料: http://blog.51cto.com/virtualadc/591396http://www.jianshu.com/p/8a61de3f8be9http://blog.csdn.net/column/details/load-balancing.
原创
发布博客 2017.11.28 ·
1008 阅读 ·
1 点赞 ·
0 评论 ·
2 收藏

如何写一个RPC框架(六):负载均衡

在后续一段时间里, 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第六篇文章, 主要讲述了RPC中负载均衡这一块的内容。常见的LB策略常见的LB策略有很多:RoundRobin (RR): 一个列表中轮着来WeightedRoundRobin (WRR): 带权重的RRLocalFirst:本地服务优先Random:随机选择ConsistentHash: 一致性哈希这些策
原创
发布博客 2017.11.19 ·
3406 阅读 ·
2 点赞 ·
0 评论 ·
2 收藏

如何写一个RPC框架(五):服务器端实现

在后续一段时间里, 我会写一系列文章来讲述如何实现一个RPC框架(我已经实现了一个示例框架, 代码在我的github上)。 这是系列第五篇文章, 主要讲述了服务器端的实现。在前面的几篇文章里, 我们已经实现了客户端创建proxy bean, 并利用它来发送请求、处理返回的全部流程: 扫描package找出需要代理的service通过服务注册中心和Load Balancer获取se
原创
发布博客 2017.11.13 ·
1083 阅读 ·
1 点赞 ·
0 评论 ·
1 收藏

如何写一个RPC框架(四):网络通信之客户端篇

在后续一段时间里, 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第四篇文章, 主要讲述了客户端和服务器之间的网络通信问题。模型定义我们需要自己来定义RPC通信所传递的内容的模型, 也就是RPCRequest和RPCResponse。@Data@Builderpublic class RPCRequest { private String requestId; pr
原创
发布博客 2017.11.12 ·
2128 阅读 ·
2 点赞 ·
1 评论 ·
3 收藏

如何写一个RPC框架(三):服务注册与服务发现

在后续一段时间里, 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第三篇文章, 主要讲述了服务注册和服务发现这一块。在系列的第一篇文章中提到,我们的RPC框架需要有一个服务注册中心。 通过这个中心,服务可以把自己的信息注册进来,也可以获取到别的服务的信息(例如ip、端口、版本信息等)。这一块有个统一的名称,叫服务发现。对于服务发现,现在有很多可供选择的工具,例如zookeeper, et
原创
发布博客 2017.11.01 ·
3639 阅读 ·
1 点赞 ·
1 评论 ·
3 收藏

如何写一个RPC框架(二):利用Bean容器和动态代理简化客户端代码

在后续一段时间里, 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第二篇文章, 主要讲述了如何利用Spring以及Java的动态代理简化调用别的服务的代码。在本系列第一篇文章中,我们说到了RPC框架需要关注的第一个点,通过创建代理的方式来简化服务调用代码。如果不使用代理?如果我们不用代理去帮我们操心那些服务寻址、网络通信的问题,我们的代码会怎样? 我们每调用一次远端服务,就要在业务代码中
原创
发布博客 2017.10.28 ·
2162 阅读 ·
1 点赞 ·
0 评论 ·
6 收藏
加载更多