分布式处理

分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅是通过消息传递进行通信和协调的系统。 首先分布式系统一定是由多个节点组成的系统，一般来说一个节点就是我们的一台计算机；然后这些节点不是孤立的，而是相互连通的；最后，这些连通的节点上部署了我们的组件，并且互相之间的操作会有协同。 升级单机处理能力的性价比越来越低。 大型主机的人才培养成本非常之高，大型主机操作非常复杂，对运维人员的要求非常高。 大型主机非常昂贵。通常一台配置比较好的IBM大型主机，其售价在上百万美元甚至更高。 根据摩尔定律，在一个确定的时间点，通过更换硬件做垂直拓展的方式来提升性能会越来越不划算。 单机处理能力存在瓶颈。 在某个固定的时间点，单颗处理器有自己的性能瓶颈，也就是说即使你愿意话更多的钱去买计算能力也买不到了。 出于稳定性和可用性的考虑。 集中式的系统具有明显的单点问题。大型主机虽然在性能和稳定性方面表现卓越，但是一旦出现了故障，那么整个系统都将处于不可用状态，其后果相当严重。 缺乏全局时钟：分布式系统是由多个节点组成，通过多个进程之间的交换消息来进行通信。由于每个节点都拥有自己单独的时钟，没有一个全局的时钟，所以很难定义两个事件的先后顺序。对于这种情况，我们可以把这个工作交给一个单独的集群来完成，通过这个集群来区分多个动作的顺序。 面对故障独立性：在分布式系统中

课程简介： 升级版的内容特色： 面向人群： 学习收益： 课程大纲： 第一课 静态网页爬虫：爬虫的基础技术 HTML CSS 选择器 JavaScript 介绍 lxml 及 XPath Python 里的网络请求 高速位缓存设计：BloomFilter 第一个爬虫：蚂蜂窝的游记 第二课 登录及动态网页的抓取 表单 网站登录及Cookie Headless 的浏览器：PhantomJS 浏览器的驱动：Selenium 动态网页数据获取 第三课 微博的抓取 微博网站分布及结构分析 通过动态页面来抓取 微博网络接口的逆向分析 Java 的反编译 加密库 源代码的接口分析 第四课 多线程与过进程的爬虫 第五课 微博数据的存储：分布式数据库及应用 SQL 与 NoSQL Hadoop 架构 HDFS HBase MongoDB Redis 基于分布式数据库的分布式爬虫 第六课 多机并行的微博抓取：分布式系统设计 Socket 编程 Master 设计 Slave 设计 任务调度及通信协议 分布式集群部署的爬虫 第七课 分布式系统进阶：复杂的分布式机制 分布式应用协调服务：ZooKeeper 分布式消息队列管理：RabbitMQ/Kafka 服务发布及注册 灰度升级 第八课 微博数据查询：分布式数据库系统的优化及负载均衡 复制与分片 流量控制及均衡 分布式事物及锁 Redis 的核心技术介绍

前言 随着互联网的发展，各种高并发、海量处理的场景越来越多。为了实现高可用、可扩展的系统，常常使用分布式，这样避免了单点故障和普通计算机cpu、内存等瓶颈。 但是分布式系统也带来了数据一致性的问题，比如用户抢购秒杀商品多台机器共同执行出现超卖等。有些同学容易将分布式锁与线程安全混淆，线程安全是指的线程间的协同。如果是多个进程间的协同需要用到分布式锁，本文总结了几种常见的分布式锁。 基于数据库 悲观锁―事务 比如用户抢购秒杀商品的场景，多台机器都接收到了抢购的请求，可以将获取库存、判断有货、用户付款、扣减库存等多个数据库操作放到一个事务，这样当一台机器与数据库建立链接请求了抢购商品这个事务，另外的机器只能等这个机器将请求完成才能操作数据库。在实际应用场景中，常常库存与交易是两个独立的系统，这时的事务是一个分布式事务，需要用到两段式、三段式提交。 优点：是比较安全的一种实现方法。 缺点：在高并发的场景下开销是不能容忍的。容易出现数据库死锁等情况。 乐观锁―基于版本号 乐观锁常常用于分布式系统对数据库某张特定表执行update操作。考虑线上选座的场景，用户A和B同时选择了某场次电影的一个座位，都去将座位的状态设置为已售。 设想这样的执行序列： 1、用户A判断该座位为未售状态； 2、用户B判断该座位为未售状态； 3、用户A执行update座位为已售； 4、用户B执行update座位为已售。

集群 小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。 分布式 为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群。 节点 节点是指一个可以独立按照分布式协议完成一组逻辑的程序个体。在具体的项目中，一个节点表示的是一个操作系统上的进程。 副本机制 副本(replica/copy)指在分布式系统中为数据或服务提供的冗余。 数据副本指在不同的节点上持久化同一份数据，当出现某一个节点的数据丢失时，可以从副本上读取到数据。（张三请假了，李四负责顶替张三的工作）数据副本是分布式系统中解决数据丢失问题的唯一手段。 服务副本表示多个节点提供相同的服务，通过主从关系来实现服务的高可用方案。 中间件 中间件位于操作系统提供的服务之外，又不属于应用，他是位于应用和系统层之间为开发者方便的处理通信、输入输出的一类软件，能够让用户关心自己应用的部分。 一个成熟的大型网站系统架构并不是一开始就设计的非常完美，也不是一开始就具备高性能、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步完善演变过来的。在这个过程中，开发模式、技术架构等都会发生非常大的变化。 阶段一，单应用架构

事务的特性ACID 事务提供了一种机制，可用来将一系列数据库更改归入一个逻辑操作。更改数据库后，所做的更改可以作为一个单元进行提交或取消。事务可确保遵循原子性、一致性、隔离性和持续性（ACID）这几种属性，以使数据能够正确地提交到数据库中。 1.脏读 一个事务正在对数据进行更新操作，但是更新还未提交，另一个事务这时也来操作这组数据，并且读取了前一个事务还未提交的数据，而前一个事务如果操作失败进行了回滚，后一个事务读取的就是错误的数据，这样就造成了脏读 2.不可重复读 3.幻读 第一个数据正在查询某一条数据，这时，另一个事务又插入了一条符合条件的数据，第一个事务在第二次查询符合同一条件的数据时，发现多了一条前一次查询时没有的数据，仿佛幻觉一样，这就是幻读 不可重复读是指在同一查询事务中多次进行，由于其他提交事务所做的修改和删除，每次返回不同的结果集，此时发生不可重复读 幻读是指在同一查询事务中多次进行，由于其他提交的事务所做的插入操作，每次返回不同的结果集，此时发生幻读表面上看，区别就在于不可重复读能看见其他事务提交的修改和删除，而幻读能看见其他事务提交的插入 1.default：(默认) 默认隔离级别，使用数据库默认的事务隔离级别 2.read_uncommitted:(读未提交) 这是事务最低的隔离级别,他允许另外一个事务可以看到这个事务未提交的数据,这种隔离级别会产生脏读

分布式系统一致性问题解决实战 一、背景及问题描述 业务背景： 商户提交表单数据至旺铺（deco项目，以下皆称为deco），deco需要接入poi系统进行装修内容的人工审核，详细流程见下图。 问题： 店铺装修审核状态在deco系统和poi系统之间不一致，下图中1，2，3步提交流程会出现同一次提交审核流在deco系统中的装修状态为未装修，而在poi系统为审核中。同样在4，5，6步骤的审核回调过程也会有同类的状态不一致问题。两块问题都是同一技术问题，本文只以1，2，3步提交过程为例进行分析解决。 二、问题分析 1. 关系型数据事务在分布式系统中的问题 从业务中抽离出来，问题的核心原因可用下图流程模型来描述。 系统A的某个业务功能包含两步操作，第一步把数据写入A系统本地库，第二步远程调用系统B，这两步操作在A系统用一个数据库事务来包装。伪代码如下： $db->begain(); // 第一步操作本地数据库 $res = $db->update($sql_a); if (!$res) { $db->rollback(); return; } // 第二步远程调用B系统 $res = $http_request->get($url_b); if ('success' != $res) { $db->rollback(); return; } $db->commit(); 第一步有两种结果成功

微服务架构是一种软件架构风格，将一个复杂的应用拆分为多个服务模块，每个模块负责单一的业务功能对外服务，并且可以单独编译部署。每个模块单独部署，模块之间无法直接通信，所以需要借助RPC（远程过程通信协议）或者通过HTTP协议让模块之间进行通信。dubbo 是一套微服务系统的协调者。运用dubbo时将dubbo的jar引入项目中然后项目初始化的时候就会将当前系统需要发布的服务以及当前系统的IP和端口号发送给注册中心；以及描述当前系统所需要的服务，然后向注册中心请求这些服务所在的IP和端口号。 分布式： 将以一个业务拆分为多个子业务，部署在不同的服务器上。分布式和微服务是一样的。 集群： 分布式是以缩短单个任务的执行时间来提升效率，集群是通过单位时间内执行的效率来提高效率的，集群的每台服务器上部署的是同样的服务，他是有组织性的，一台服务器崩了，其他服务器可以顶上来。而分布式的每个节点都完成不同的功能，如果一个节点崩了则此服务器的服务无法访问，所以最好就是分布式+集群部署。 负载均衡： 负载均衡其实就是集群的前置。集群部署完后，需要一台服务器充当调度者角色，用户的所有请求首先被此调度者服务器接收，然后根据每台服务器的负载情况分发请求。 <HTTP重定向实现负载均衡> 当用户请求某个服务时，请求首先被调度者服务器截获，然后根据某种策略选择集群中的一台服务器

目录： 一、什么是分布式系统？ 二、为什么要走分布式系统架构？ 三、系统如何进行拆分？ 四、分布式之后带来的技术挑战？ 一、什么是分布式系统？ 在谈分布式系统架构前，我们先来看看，什么是分布式系统？ 假设原来我们有一个系统，代码量30多万行。现在拆分成20个小系统，每个小系统1万多行代码。 原本代码之间都是直接基于Spring框架走JVM内存调用，现在拆开来，将20个小系统部署在不同的机器上，然后基于分布式服务框架（比如dubbo）搞一个rpc调用，接口与接口之间通过网络通信来进行请求和响应。 所以分布式系统很重要的特点就是服务间要跨网络进行调用，我们来看下面的图： 此外，分布式系统可以大概可以分成两类。 1. 底层的分布式系统。 比如hadoop hdfs（分布式存储系统）、spark（分布式计算系统）、storm（分布式流式计算系统）、elasticsearch（分布式搜索系统）、kafka（分布式发布订阅消息系统）等。 2. 分布式业务系统 分布式业务系统，把原来用java开发的一个大块系统，给拆分成多个子系统，多个子系统之间互相调用，形成一个大系统的整体。 举个例子，假设原来你做了一个OA系统，里面包含了权限模块、员工模块、请假模块、财务模块，一个工程，里面包含了一堆模块，模块与模块之间会互相去调用，1台机器部署。 现在如果你把他这个系统给拆开，权限系统，员工系统，请假系统

分布式并行计算MapReduce 一、用自己的话阐明Hadoop平台上HDFS和MapReduce的功能、工作原理和工作过程。 1.HDFS: Hadoop Distributed File System Hadoop分布式文件系统 1.1功能： 1.兼容廉价的硬件设备。2.流数据的读写。3.大数据集。4.简单的文件模型。5.强大的夸平台兼容性。 1.2工作原理：客户端要向HDFS写数据，首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode，然后客户端按顺序将文件逐个block传递给相应datanode，并由接收到block的datanode负责向其他datanode复制block的副本。 1.3工作过程： 2.MapReduce 2.1功能：MapReduce是一种并行可扩展计算模型，并且有较好的容错性，主要解决海量离线数据的批处理。实现下面目标 易于编程、良好的扩展性、高容错性 2.2工作原理：MapReduce是一种可用于数据处理的编程框架。MapReduce采用"分而治之"的思想，把对大规模数据集的操作，分发给一个主节点管理下的各个分节点共同完成，然后通过整合各个节点的中间结果，得到最终结果。简单地说，MapReduce就是"任务的分解与结果的汇总"。 在分布式计算中，MapReduce框架负责处理了并行编程中分布式存储、工作调度、负载均衡

群里经常卧虎藏龙，转载一篇百度大牛，投稿原创文章，大家交流学习 ，欢迎更多朋友投稿，发布原创文章和干货和大家分享交流。 引言 在互联网系统中，理想的情况下，肯定是希望系统能够同时满足“一致性”、“可用性”和“分区容忍性”。 但是基于熟悉的CAP定律也好，还是BASE理论， 我们知道，在实际情况中是不可能实现的。而在金融领域，一致性是最为关注的特性，任何情况下都必须满足一致性。关于CAP定律和BASE理论，本文不再介绍，有兴趣的同学可以自行百度一下。本文重点来阐述下关于一致性的方案，包括强一致性和最终一致性。 而在互联网领域， 很多情况下都是牺牲强一致性，来达到高可用性， ϵ 统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。 数据库本地事务 数据库事务肯定是强一致性的方案，而且是一致性最简单的方案，因为一致性是数据库的事务来保证的，业务层不需要关心细节。比较典型的应用是在返现场景下，针对带有返现的交易的退款，需要一次性退两笔交易单，采用的就是通过数据库本地事务来完成的。具体如下： 用户A花了100元购买商户B的商品，购买结束后返现给用户A 2元。 这是两笔交易，原始交易是100元，返现交易是2元。 那么发生退款时，需要保证两笔交易同时都退款。这个就是直接采用数据库本地事务实现的，即一次退款请求，两笔交易同时退款。 总结： 数据库事务的优点是简单