分布式技术

一、小型公司网络架构 狗子是某大学计算机专业本科应届毕业生，由于自己的技术不错，再加上互联网产业的巨大利润的驱使，狗子决定走上创业这条路，于是，狗子联合了同学二黑，鸡子，狗蛋等人花费了几个月的时间写出了一套网站，是关于足球资讯的pc端网站加上手机APP客户端。现在产品测试成功了，准备发布了，狗子想到了两个问题： 1.网站需要服务器 狗子之前所有的代码测试都是在本地服务器或者局域网上进行的，现在需要把产品发布到外网上，让所有的人都能访问，因此再用自己的电脑当服务器显然很不现实，于是，狗子去买了一台服务器，在上面装了jdk,tomcat，mysql等必备环境，把网站搭了起来，又经过了很多测试，运行毫无问题了，通过网站的ip可以访问并且实现功能了，而且app的后台也在服务器上测试成功了，目前公司的架构如图所示： 那么问题又来了： 2.网站需要域名 显然，如果让各地的用户需要记住你服务器的ip地址才能访问你的网站的话，那是会被用户拿刀追着砍的。因此，狗子需要一个便于记住的域名，以后在浏览器输入这个域名就能够访问这个网站，所以，狗子拿着申请下来的各种资质，找到了域名贩卖商，一般是腾讯阿里巴巴这种代理贩卖商，花了一笔钱，从它们的手上购买了域名，彻底实现了网站通过域名就能访问的功能。这里需要讲解一下通过域名访问的原理： 域名访问原理 通过ip访问相当于用户直接访问输入的ip所指向的服务器

分布式领域CAP理论： Consistency(一致性), 数据一致更新，所有数据变动都是同步的。 Availability(可用性), 好的响应性能。 Partition tolerance(分区容错性) 可靠性。 要做到 CP， 系统可以把这个数据只放在一个节点上，其他节点收到请求后向这个节点读或写数据，并返回结果。 要做到 CA， 一个现实的例子就是单点的数据库。 要做到 AP， 系统只要每次对写都返回成功，对读都返回固定的某个值就可以了。 CAP 理论更重要的一个结果是， 在 Partial Synchronous System (半同步系统) 中，一个弱化的 CAP 是能达到的: * 对所有的数据访问，总返回一个结果 * 如果期间没有报文丢失，那么返回一个满足 consistency 要求的结果。 很像mysql的半同步复制技术。 关系数据库的ACID模型拥有：即事物的acid属性。 Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成。 Consistency一致性. 在事务开始或结束时，数据库应该在一致状态。 Isolation隔离层. 事务将假定只有它自己在操作数据库，彼此不知晓。 Durability. 一旦事务完成，就不能返回。 来源： oschina 链接： https://my.oschina.net/u/2460176/blog

##2.1 网站架构模式## 为了解决大型网站面临的高并发访问，海量数据处理，高可靠运行等一系列问题与挑战，大型互联网公司在实践中提出了许多解决方案，以实现网站高性能，高可用，易伸缩，可扩展，安全等各种技术架构目标。这些解决方案又被更多网站重复使用，从而逐渐形成大型网站架构模式。 ###2.1.1 分层### 分层是企业应用系统中最常见的一种架构模式，将系统在 横向维度 上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。 分层结构在计算机世界中无处不在， 网络的7层通信协议 是一种分层结构；计算机硬件，操作系统，应用软件也可以看作是一种分层结构。在大型网站中也采用分层结构，将网站软件系统分为 应用层 ， 服务层 ， 数据层 ，如下： 应用层 ：负责具体业务和视图展示，如网站首页及搜索输入和结果展示； 服务层 ：为应用层提供服务支持，如用户管理服务，购物车服务等； 数据层 ：提供数据存储访问服务，如数据库，缓存，文件，搜索引擎等； 通过分层，可以更好地将一个庞大的软件系统切分成不同的部分，便于分工合作开发和维护；各层之间具有一定的独立性，只要维持调用接口不变，各层可以根据具体问题独立演化发展而不需要其他层必须做出相应调整。 但是分层架构也有一些挑战，就是 必须合理规划层次边界和接口 ，在开发过程中，严格遵循分层架构的约束

分布式设计与开发中有些疑难问题必须借助一些算法才能解决，比如分布式环境一致性问题，感觉以下分布式算法是必须了解的（随着学习深入有待添加）： Paxos算法 一致性Hash算法 Paxos算法 1）问题描述 分布式中有这么一个疑难问题，客户端向一个分布式集群的服务端发出一系列更新数据的消息，由于分布式集群中的各个服务端节点是互为同步数据的，所以运行完客户端这系列消息指令后各服务端节点的数据应该是一致的，但由于网络或其他原因，各个服务端节点接收到消息的序列可能不一致，最后导致各节点的数据不一致。举一个实例来说明这个问题，下面是客户端与服务端的结构图： 当client1、client2、client3分别发出消息指令A、B、C时，Server1~4由于网络问题，接收到的消息序列就可能各不相同，这样就可能由于消息序列的不同导致Server1~4上的数据不一致。对于这么一个问题，在分布式环境中很难通过像单机里处理同步问题那么简单，而Paxos算法就是一种处理类似于以上数据不一致问题的方案。 2）算法本身 算法本身我就不进行完整的描述和推导，网上有大量的资料做了这个事情，但我学习以后感觉莱斯利·兰伯特（Leslie Lamport，paxos算法的奠基人，此人现在在微软研究院）的 Paxos Made Simple 是学习paxos最好的文档

分布式设计与开发中有些疑难问题必须借助一些 算法 才能解决，比如分布式环境一致性问题，感觉以下分布式算法是必须了解的（随着学习深入有待添加）： Paxos算法 一致性Hash算法 Paxos算法 1）问题描述 分布式中有这么一个疑难问题，客户端向一个分布式集群的服务端发出一系列更新数据的消息，由于分布式集群中的各个服务端节点是互为同步数据的，所以运行完客户端这系列消息指令后各服务端节点的数据应该是一致的，但由于网络或其他原因，各个服务端节点接收到消息的序列可能不一致，最后导致各节点的数据不一致。举一个实例来说明这个问题，下面是客户端与服务端的结构图： 当client1、client2、client3分别发出消息指令A、B、C时，Server1~4由于网络问题，接收到的消息序列就可能各不相同，这样就可能由于消息序列的不同导致Server1~4上的数据不一致。对于这么一个问题，在分布式环境中很难通过像单机里处理同步问题那么简单，而Paxos算法就是一种处理类似于以上数据不一致问题的方案。 2）算法本身 算法本身我就不进行完整的描述和推导，网上有大量的资料做了这个事情，但我学习以后感觉莱斯利·兰伯特（Leslie Lamport，paxos算法的奠基人，此人现在在微软研究院）的 Paxos Made Simple 是学习paxos最好的文档

《程序员练级攻略》系列文章的目录。 开篇词 入门篇 零基础启蒙 正式入门 修养篇 程序员修养 专业基础篇 编程语言 理论学科 系统知识 软件设计篇 软件设计 高手成长篇 Linux 系统、内存和网络（系统底层知识） 异步 I/O 模型和 Lock-Free 编程（系统底层知识） Java 底层知识 数据库 分布式架构入门（分布式架构） 分布式架构经典图书和论文（分布式架构） 分布式架构工程设计 (分布式架构) 微服务 容器化和自动化运维 机器学习和人工智能 前端基础和底层原理（前端方向） 前端性能优化和框架（前端方向） UI/UX 设计（前端方向） 技术资源集散地 一定要坚持，要保持长时间学习，甚至终生学习的态度。 一定要动手，不管例子多么简单，建议至少自己动手敲一遍看看是否理解了里头的细枝末节。 一定要学会思考，思考为什么要这样，而不是那样。还要举一反三地思考。 不要乱买书，不要乱追新技术新名词，基础的东西经过很长时间积累，会在未来至少 10年通用。 回顾一下历史，看看历史时间线上技术的发展，你才能明白明天会是什么样的。 /*--> */ /*--> */ 要去经历大多数人经历不到的，要把学习时间花在那些比较难的地方。 要写文章就要写没有人写过的，或是别人写过，但我能写得更好的。 更重要的是，技术和知识完全是可以变现的。 一，这个技术解决什么问题？为什么别的同类技术做不到？ 二

Hadoop是Apache开源的分布式计算框架，由Java语言实现，支持对海量数据的分布式计算，其框架中最核心设计是HDFS和MapReduce。 Hadoop的优势 1）高可靠性：因为Hadoop假设计算元素和存储会出现故障，因为它维护多个工作数据副本，在出现故障时可以对失败的节点重新分布处理 2）高扩展性：在集群间分配任务数据，可方便的扩展数以千计的节点。 3）高效性：在MapReduce的思想下，Hadoop是并行工作的，以加快任务处理速度。 4）高容错性：自动保存多份副本数据，并且能够自动将失败的任务重新分配。 Hadoop组成 1）Hadoop HDFS：一个高可靠、高吞吐量的分布式文件系统。 2）Hadoop MapReduce：一个分布式的离线并行计算框架。 3）Hadoop YARN：作业调度与集群资源管理的框架。 4）Hadoop Common：支持其他模块的工具模块。 1 Hadoop生态圈重要组件(数据处理过程的视角) 1.1 数据采集 Sqoop—— 结构化数据/数据迁入迁出工具 Flume Kafka—— 分布式日志采集工具 分布式消息队列 针对半结构化或非结构化数据 1.2 数据存储 HDFS—— 基于Hadoop的分布式文件存储系统 HBase—— 基于Hadoop的列式分布式NoSQL数据库 1.3 资源调度 YARN—— 作业调用和集群资源管理框架

面试题1. 说一下的 dubbo 的工作原理？注册中心挂了可以继续通信吗？说说一次 rpc 请求的流程？ 面试官心理分析 MQ、ES、Redis、Dubbo，上来先问你一些思考性的问题、原理，比如 kafka 高可用架构原理、es 分布式架构原理、redis 线程模型原理、Dubbo 工作原理；之后就是生产环境里可能会碰到的一些问题，因为每种技术引入之后生产环境都可能会碰到一些问题；再来点综合的，就是系统设计，比如让你设计一个 MQ、设计一个搜索引擎、设计一个缓存、设计一个 rpc 框架等等。 那既然开始聊分布式系统了，自然重点先聊聊 dubbo 了，毕竟 dubbo 是目前事实上大部分公司的分布式系统的 rpc 框架标准，基于 dubbo 也可以构建一整套的微服务架构。但是需要自己大量开发。 当然去年开始 spring cloud 非常火，现在大量的公司开始转向 spring cloud 了，spring cloud 人家毕竟是微服务架构的全家桶式的这么一个东西。但是因为很多公司还在用 dubbo，所以 dubbo 肯定会是目前面试的重点，何况人家 dubbo 现在重启开源社区维护了，捐献给了 apache，未来应该也还是有一定市场和地位的。 既然聊 dubbo，那肯定是先从 dubbo 原理开始聊了，你先说说 dubbo 支撑 rpc 分布式调用的架构啥的，然后说说一次 rpc

多级缓存的分层架构 前言 在互联网高速发展的今天，缓存技术被广泛地应用。无论业内还是业外，只要是提到性能问题，大家都会脱口而出“用缓存解决”。 这种说法带有片面性，甚至是一知半解，但是作为专业人士的我们，需要对缓存有更深、更广的了解。 缓存技术存在于应用场景的方方面面。从浏览器请求，到反向代理服务器，从进程内缓存到分布式缓存。其中缓存策略，算法也是层出不穷，今天就带大家走进缓存。 正文 缓存对于每个开发者来说是相当熟悉了，为了提高程序的性能我们会去加缓存，但是在什么地方加缓存，如何加缓存呢？ 假设一个网站，需要提高性能，缓存可以放在浏览器，可以放在反向代理服务器，还可以放在应用程序进程内，同时可以放在分布式缓存系统中。 从用户请求数据到数据返回，数据经过了浏览器，CDN，代理服务器，应用服务器，以及数据库各个环节。每个环节都可以运用缓存技术。 从浏览器/客户端开始请求数据，通过 HTTP 配合 CDN 获取数据的变更情况，到达代理服务器（Nginx）可以通过反向代理获取静态资源。 再往下来到应用服务器可以通过进程内（堆内）缓存，分布式缓存等递进的方式获取数据。如果以上所有缓存都没有命中数据，才会回源到数据库。 缓存的请求顺序是：用户请求 → HTTP 缓存 → CDN 缓存 → 代理服务器缓存 → 进程内缓存 → 分布式缓存 → 数据库。 看来在技术的架构每个环节都可以加入缓存

Sharding-JDBC 3.x 原理篇之基本介绍 简介 功能介绍 Sharding-JDBC Sharding-Proxy Sharding-Sidecar 混合架构 各大版本间的区别与变化 1.x 功能列表 2.x 功能清单 3.x 功能清单 规划线路图 相关文档及实例 简介 Sharding-JDBC是当当开源的数据库水平切分的中间件，其代表了客户端类的分库分表技术框架（这一点与MyCat不同，MyCat本质上是一种数据库代理）。Sharding-JDBC定位为轻量级数据库驱动，由客户端直连数据库，以jar包形式提供服务，未使用中间层，无需额外部署，无其他依赖，业务系统开发人员与数据库运维人员无需改变原有的开发与运维方式。因此Sharding-JDBC即为增强版的JDBC驱动，可以实现旧代码迁移零成本的目标。 　　目前社区较为活跃。目前已广泛应用于现各大互联网公司。通过社区得知，Sharding-JDBC的作者已去京东做全职的Sharding-JDBC开发，相信未来Sharding-JDBC社区的发展将会更好。 功能介绍 目前Sharding-JDBC共有3个主要模块，分别为Sharding-JDBC、Sharding-Proxy、Sharding-Sidecar Sharding-JDBC 定位为轻量级Java框架，在Java的JDBC层提供的额外服务。