分布式技术

随着互联网、云计算及大数据等信息技术的发展，越来越多的应用依赖于对海量数据的存储和处理，如智能监控、电子商务、地理信息等，这些应用都需要对海量图片的存储和检索。由于图片大多是小文件(80%大小在数MB以内)，以GFS、HDFS为代表的适用于流式访问大文件的分布式存储系统，若直接用来存储图片，由于元数据膨胀，在扩展性和性能方面均存在严重问题。 为了解决HDFS在小文件存储方面的问题，通常的做法是先将很多小文件合并成一个大文件再保存到HDFS，同时为这些小文件建立索引，以便进行快速存取。典型技术包括Hadoop自带的Archive、SequenceFile，但均需要用户自己编写程序，实现小文件的合并。为了实现小文件合并对用户的透明，需从系统层面解决HDFS小文件问题。论文针对具体应用场景进行了探索，但不具有通用性。 SandStone MOS海量图片解决方案 对于海量图片数据的存储问题，杉岩海量对象存储（SandStone MOS）解决方案采用去中心化分布式架构，同时利用软件定义的方式实现了单一名字空间条件下数百PB级规模的容量扩展，业务可以随时随地访问而不受数据存储位置的限制。 在提升海量小文件访问性能方面，SandStone MOS利用哈希计算实现了数亿级文件的高效访问。针对文件检索困难，SandStone MOS支持标签功能，文件存储时会自动设置标签，从而更好地与业务结合

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 随着公司业务规模的扩大，网站访问量日益剧增，最初的系统架构可能已经没办法满足业务发展的需求了。这时候就要考虑将系统架构改造成扩展性更强，能够承受更大访问量的分布式架构。 本文从大致三个方面谈谈分布式架构的概念、原理和相关的解决方案。为什么要做分布式？举个栗子，就好比原来城市的道路是双车道，同一时间只能容纳很小一部分车流量，但是改成多车道后，道路的容量就提升了几倍，网站也是相同的道理，用户的访问请求就是汽车，分布式架构就是在构建一个多车道的网站系统。接下来我们具体聊一聊各个层面的分布式技术解决方案。首先讲业务层的分布式，最简单的就是部署几台业务服务器，部署Apache或者Nginx，配置相同（vhost、域名解析、代码目录等），然后使用负载均衡技术将这几台服务器组成集群，达到对用户分流的效果。需要注意的是SESSION会话需要保存到数据库或者缓存系统中，保证SESSION的一致性，至于数据库，有统一的数据层，不需要担心数据不一致的问题。负载均衡有很多种解决方案，比较常见的是LVS（阿里巴巴章文嵩博士开发）、Nginx（阿里巴巴优化的Tengine）、HAProxy等。LVS是负责在4层网络实现负载均衡，有DR、隧道等方式，可以根据自身需求选择合适的方式。Nginx和HAProxy是负责7层网络的负载均衡

分布式追踪系统 使用 Zipkin 和 Brave 实现分布式系统追踪（基础篇） - 推酷 OpenZipkin · A distributed tracing system Twitter zipkin 分布式跟踪系统的设计与实现 - 马宏的世界 - 博客频道 - CSDN.NET openzipkin/brave: Java distributed tracing implementation compatible with Zipkin backend services. openzipkin/zipkin: Zipkin is a distributed tracing system zipkin - liaokailin的专栏 - 博客频道 - CSDN.NET #研发解决方案介绍#Tracing（鹰眼） - 旁观者 - 博客园 分布式系统为什么需要 Tracing？ 先介绍一个概念： 分布式跟踪 ，或 分布式追踪 。 电商平台由数以百计的分布式服务构成，每一个请求路由过来后，会经过多个业务系统并留下足迹，并产生对各种Cache或DB的访问，但是这些分散的数据对于问题排查，或是流程优化都帮助有限。对于这么一个跨进程/跨线程的场景，汇总收集并分析海量日志就显得尤为重要。 要能做到追踪每个请求的完整调用链路，收集调用链路上每个服务的性能数据，计算性能数据和比对性能指标（SLA

ZooKeeper是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper通过其简单的架构和API解决了这个问题。ZooKeeper允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。 ZooKeeper框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。 后来，Apache ZooKeeper成为Hadoop，HBase和其他分布式框架使用的有组织服务的标准。 例如，Apache HBase使用ZooKeeper跟踪分布式数据的状态。 先来介绍一下分布式： 分布式应用 分布式应用可以在给定时间（同时）在网络中的多个系统上运行，通过协调它们以快速有效的方式完成特定任务。通常来说，对于复杂而耗时的任务，非分布式应用（运行在单个系统中）需要几个小时才能完成，而分布式应用通过使用所有系统涉及的计算能力可以在几分钟内完成。 通过将分布式应用配置为在更多系统上运行，可以进一步减少完成任务的时间。分布式应用正在运行的一组系统称为 集群 ，而在集群中运行的每台机器被称为 节点 。 分布式应用有两部分， Server（服务器） 和 Client（客户端） 应用程序。服务器应用程序实际上是分布式的，并具有通用接口，以便客户端可以连接到集群中的任何服务器并获得相同的结果。

2019最新JAVA架构师视频资料，搭建高并发，高并发解决方案，高可用电商架构视频教程分布式框架,高可用框架,微服务架构,数据库优化39套Java架构师，高并发，高性能，高可用，分布式，集群，电商，缓存，微服务，微信支付宝支付，公众号开发，java8新特性，P2P金融项目，程序设计，功能设计，数据库设计，第三方支付，web安全，性能调优，设计模式，数据结构，并发编程，虚拟机，中间件，数据库，项目实战，大型分布式电商项目实战视频教程 视频课程包含： 39套包含：架构师，高并发，高性能，高可用，高可扩展，分布式，集群，电商，缓存，微服务，微信支付宝支付，公众号开发，java8新特性，P2P金融项目，程序设计，功能设计，数据库设计，架构设计，web安全，性能调优，设计模式，数据结构，项目实战，工作流，程序调优，负载均衡，Solr集群与应用，主从复制，中间件，全文检索，任务调度，jvm虚拟机，Spring boot，Spring cloud，Docker，Kubernetes，jvm，Dubbo，Elasticsearch，ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat，Spring，Git，Nosql，Mecached，Netty，Nio，Mina，Nutch，Webservice，Activiti，Shiro，Tomcat，Mysql，Oracle

在 关于分布式事务的理解 一文中，最后留了一个坑是关于TCC框架的。当时由于时间问题耽搁了，最近总算有时间把这个坑填上了。 本文会大致介绍下两阶段和三阶段提交，以及TCC模式。 分布式事务分为 两阶段型 补偿型 异步确保型 最大努力通知型几种 上文我们已近介绍了 异步确保型 和 最大努力通知 这两种服务模式的具体应用，接下来介绍下剩下两种。 两阶段提交（2PC）型 两阶段型：就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS。 准备阶段 事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。 可以进一步将准备阶段分为以下三个步骤： 协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。 （注意：若成功这里其实每个参与者已经执行了事务操作） 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功， 则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。 提交阶段 如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚

1、分布式系统简介： 多个节点： 容错性 可扩展性（性能） 固有分布性 消息传递： 节点具有私有存储 易于开发 可扩展性（功能） 对比：并行计算 完成特定的需求： 消息传递的方法： REST（动作、URL） RPC（序列化传输、远端序列化后调用） 中间件（可以存储消息、一对多、消息队列） 一般消息传递的方法： 对外：REST 模块内部：RPC 模块之间：中间件，REST 分布式架构VS为微服务架构 分布式：指导节点之间如何通信 微服务：鼓励按业务划分模块 微服务架构通过分布式架构来实现 多层架构VS微服务架构 微服务架构具有更多的“服务” 微服务通常需要配合自动化测试，部署，服务发现等 目前我们倾向于微服务架构 2、分布式爬虫架构： 并发版爬虫的架构： 目前的问题： 限流问题 去重问题 数据存储问题（固有分布式） 解决限流问题： 单节点能够承受的流量有限–> 将worker放到不同的节点 每个机器都可以起很多worker，任务不一定分发到本机的worker 解决去重问题： 单节点能承受的去重数据量有限 无法保存之前去重结果 基于Key-Value Store（如Redis）进行分布式去重 每来一个请求都要去连接一次去重服务，容易被卡住，所以需要把去重的工作交给worker，worker卡住 没关系，可以起很多个goroutine的worker 解决存储问题： 存储部分的结构

前言 随着大型网站的各种高斌发访问、海量数据处理等场景越来越多，如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。为了解决这样一系列问题。大型网站的架构也在不断发展。提高大型网站的高可用架构，就不得不提 分布式系统（Distributed Systems） 。下面说一下分布式系统及其相关的概念 在学习分布式系统之前，先了解一下与之相对应的集中式系统是什么样的。 集中式系统 集中式系统，主要指IBM、HP一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行，也就是我们平常说的单机服务器。 集中式系统的最大特点就是不熟结构非常简单，底层一般采用IBM、HP等厂商购买的昂贵的大型主机。因此无需要考虑如何对服务进行多节点的部署，也就不用考虑各节点的分布式协作问题。但是，由于采用单机部署、和可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。 说完集中式系统，再来说一个与分布式很相似的概念-集群 集群 集群是一组独立的计算机系统构成一个松耦合的多处理器系统，它们之间通过网络实现进程间的通信。用来提供比集中式系统更具扩展性与可用性的服务平台。集群有两个关键的特性： 可扩展性，集群的性能不限于单一的服务实体，新的服务实体可以动态地添加到集群

分布式计算就是通过计算机网络将计算工作分布到多台主机上，多个主机一起协同完成工作。 我试着列一下相关知识吧。 网络通讯，网络是分布式的基础，对分布式的理解建立在对网络的理解上，包括： OSI模型的7层 TCP/IP，DNS，NAT HTTP，SPDY/HTTP2 Telnet 网络编程，是通过程序在多个主机之间通信。包括： Socket 多线程 非阻塞IO 网络框架 Netty Mina ZeroMQ 操作系统的网络部分 RPC，Socket使用不是很方便，很多分布式应用是基于RPC的，包括： 同步RPC 异步RPC 主要的一些RPC协议 RMI Rest API Thrift 集群，分布式计算离不开集群。集群就是多台主机被当作一个系统 集群类型 高可用，如主机备机切换，冷备，热备，双活 伸缩性，如Web服务器集群，数据库服务器的Sharding 并行计算，如网格，大数据 集群相关技术，包括： 高可用性，保证服务一直能够被访问，延长MTBF，缩短MTTR 冗余的设备 多副本，为了避免单点失效 负载均衡，如何将大量工作负载分配到多个主机上，最大化吞吐量，最小化平均响应时间，最大化资源利用率。 伸缩性（横向），能够添加计算机和设备来应对增长的计算压力 分片（Sharding），把数据分成多个数据集，由多个服务器来分别处理。 自动分片 容错性，当硬件或软件发生故障，能够继续运转 故障检测

　　很长一段时间，对分布式系统都比较感兴趣，也听说过、了解过其中一些相关的知识点，但都比较零碎。一直想系统的学习一下，但是一拖再拖，写下本文，也是希望能督促自己。 写在前面 　　听过很多道理，却依然过不好这一生。 　　看过很多关于学习的技巧、方法，却没应用到自己的学习中。 　　随着年纪变大，记忆力越来越差，整块的时间也越来越少，于是，越来越希望能够更高效的学习。学习是一种习惯也是一种能力，这种能力在上学期间养成是最好的，毕竟那个时候绝大部分时间都在学习。但很遗憾，我没有养成适合自己的、好的学习习惯。工作之后，除了在日常工作中用到的知识技术，很难通过自学掌握新的知识（偏向于专业知识，即技术）。而互联网行业的分支、知识点又是如此之多，于是会出现这样的情况，遇到一个新的知识，觉得很厉害很感兴趣，看两天，但很快就忘记了。另外，对于一些比较庞杂的技术，又无从下手，也很难坚持下去。 　　根本的问题在于学习不系统，没有把一个个的知识点连接起来，本来这些新的知识就很少在工作中实践，如果又是一个个的信息孤岛，很快就会被遗忘。另一个问题，没有良好的规划，今天看看这里，明天看看哪里，纠结于细枝末节，忘了从整体上把握。 　　幸好，差不多半年前开始意识到了这个问题，开始看书，看别人的博客，开始思考如何充分利用好有限的时间。自己也实践了一些想法，比如写博客，坚持写博客。也有很多没做好