分布式架构

什么是分布式锁 要介绍分布式锁，首先要提到与分布式锁相对应的是线程锁、进程锁。 1.线程锁 主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如Synchronized、Lock等。 2.进程锁 为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁。 3.分布式锁 当多个进程不在同一个系统中，用分布式锁控制多个进程对资源的访问。 分布式锁的由来 在传统单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLcok或synchronized)进行互斥控制。 但是在分布式系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机并发控制锁策略失效，为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁的由来。 当多个进程不在同一个系统中，就需要用分布式锁控制多个进程对资源的访问。 分布式锁的特点 首先，为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件： **1、互斥性：**任意时刻，只能有一个客户端获取锁，不能同时有两个客户端获取到锁。 **2、安全性：*

“ 不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付。 又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。 有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。 简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。 数据库本地事务 ACID 说到数据库事务就不得不说，数据库事务中的四大特性 ACID： A：原子性(Atomicity)， 一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行，要么发不出货，就退钱。 C：一致性(Consistency)， 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。 如果事务成功地完成

1 微服务的发展 微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇，很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。Hailo有160个不同服务构成，NetFlix有大约600个服务。国内方面，阿里巴巴、 腾讯 、 360 、京东、58同城等很多互联网公司都进行了微服务化实践。当前微服务的开发框架也非常多，比较著名的有 Dubbo 、 SpringCloud 、 thrift 、 grpc 等。 2 微服务落地存在的问题 虽然微服务现在如火如荼，但对其实践其实仍处于探索阶段。很多中小型互联网公司，鉴于经验、技术实力等问题，微服务落地比较困难。如著名架构师Chris Richardson所言，目前存在的主要困难有如下几方面： 1）单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变的更加复杂。 2）系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。 3）微服务数量众多，其测试、部署、监控等都变的更加困难。 随着RPC框架的成熟，第一个问题已经逐渐得到解决。例如dubbo可以支持多种通讯协议，springcloud可以非常好的支持restful调用。对于第三个问题，随着docker

备份 备份软件 Amanda -客户端-服务器模型备份工具 Bacula - 另一个客户端-服务器模型备份工具 Backupninja -轻量级，可扩展的元数据备份系统 Backuppc -客户端-服务器模型备份工具和文件共享方案。 Burp -网络备份和还原程序 Duplicity -使用rsync算法加密的带宽-效率备份 Lsyncd -监控一个本地目录树的变化,然后产生一个进程去同步变化。默认使用rsync。 Rsnapshot -文件系统快照工具 SafeKeep -使用rdiff-backup，集中的，基于pull的备份 TarSnap - 具有一个开源客户端的安全备份服务 UrBackup -另一个客户端-服务器备份系统 DREBS - AWS EBS支持策略的备份脚本 克隆 克隆软件 Clonezilla -分区和磁盘镜像/克隆程序 Fog - 另一个计算机克隆解决方案 Redo Backup -简单的备份，恢复和还原 云计算 AppScale – 兼容Google App引擎的开源云计算软件. Archipel -使用Libvirt管理和监视虚拟机 CloudStack -创建，管理和部署基础云服务的云计算软件 Cobbler -Cobbler是一个Linux安装服务器，允许快速地构建网络安装环境 Eucalyptus -兼容AWS的开源私有云软件 Mesos

一、场景需求 二、Keepalived 简要介绍 Keepalived 是一种高性能的服务器高可用或热备解决方案，Keepalived 可以用来防止服务器单点故障的发生，通过配合 Nginx 可以实现 web 前端服务的高可用。 Keepalived 以 VRRP 协议为实现基础，用 VRRP 协议来实现高可用性(HA)。VRRP(Virtual Router Redundancy Protocol)协议是用于实现路由器冗余的协议，VRRP 协议将两台或多台路由器设备虚拟成一个设备，对外提供虚拟路由器 IP(一个或多个)，而在路由器组内部，如果实际拥有这个对外 IP 的路由器如果工作正常的话就是 MASTER，或者是通过 算法 选举产生，MASTER 实现针对虚拟路由器 IP 的各种网络功能， 如 ARP 请求，ICMP，以及数据的转发等；其他设备不拥有该虚拟 IP，状态是 BACKUP，除了接收 MASTER 的VRRP 状态通告信息外，不执行对外的网络功能。当主机失效时，BACKUP 将接管原先 MASTER 的网络功能。VRRP 协议使用多播数据来传输 VRRP 数据，VRRP 数据使用特殊的虚拟源 MAC 地址发送数据而不是自身网卡的 MAC 地址，VRRP 运行时只有 MASTER 路由器定时发送 VRRP 通告信息，表示 MASTER 工作正常以及虚拟路由器 IP(组)

这篇文章将介绍什么是分布式事务，分布式事务解决什么问题，对分布式事务实现的难点，解决思路，不同场景下方案的选择，通过图解的方式进行梳理、总结和比较。 相信耐心看完这篇文章，谈到分布式事务，不再只是有“2PC”、“3PC”、“MQ的消息事务”、“最终一致性”、“TCC”等这些知识碎片，而是能够将知识连成一片，形成知识体系。 什么是事务 介绍分布式事务之前，先介绍什么是事务。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。 简单地说，事务提供一种“ 要么什么都不做，要么做全套（All or Nothing）”机制。 数据库事务的 ACID 属性 事务是基于数据进行操作，需要保证事务的数据通常存储在数据库中，所以介绍到事务，就不得不介绍数据库事务的 ACID 特性。 ACID 指数据库事务正确执行的四个基本特性的缩写，包含： 原子性（Atomicity） 整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 例如：银行转账，从 A 账户转 100 元至 B 账户，分为两个步骤： 从 A 账户取 100 元。

分布式存储 — 硬盘容量不均衡导致的缓存盘寿命急速衰减分析 Ceph 分布式存储在扩展性、可靠性、性能上具备独特的优势，可以实现快速扩展多台服务器，动态伸缩到 PB 级容量，多副本机制保障数据高可靠，数据均衡分布，并发性能高等场景。目前广泛应用于互联网、科研、教育、制造业、政府等诸多领域。 ZStack 云平台目前支持对接 Ceph 分布式存储，使用的是分布式块存储，即使用 librbd 的块设备接口提供给 Qemu 访问，进行云主机、云盘的 IO 读写。 虽然 Ceph 分布式存储具备上述的优势特点，但在实践中，对硬件的选择及配置均存在特别要求，尤其是硬盘、网络上，如果配置不当，存储的可靠性和性能均会受到影响。 最近在日常巡检一套 ZStack 生产环境的 Ceph 分布式存储时，我们发现客户新购的五台服务器的 SSD 寿命损耗存在异常。具体的现象是使用半年后，服务器带外管理界面看到 SSD 的寿命损耗只剩下 89% ，但使用 smartctl 读取介质损耗参数依然显示为 100% 。 此时会很疑惑，到底哪个数据更可靠，如果 SSD 寿命只剩下 89% ，那么如何去调整优化 Ceph 分布式存储？ 问题回顾 针对这个问题，我们回顾一下这套分布式存储的架构。当时采用了新购 + 利旧的方案来部署分布式存储。 相应的配置信息如下： 其中，新购的 5 台机器采用了 Intel Xeon

点击下载《不一样的 双11 技术：阿里巴巴经济体云原生实践》 本文节选自《不一样的 双11 技术：阿里巴巴经济体云原生实践》一书，点击上方图片即可下载！ 作者 | 李云（花名：至简） 阿里云高级技术专家 导读 ：在即将过去的 2019 年，Service Mesh 开源产品的成熟度虽在全球范围内没有发生质的变化，但在国内仍出现了一些值得特别关注的事件。比如：阿里巴巴在 双11 的部分电商核心应用上落地了完整的 Service Mesh 解决方案，借助 双11 的严苛业务场景完成了规模化落地前的初步技术验证。本文作者将结合自己在阿里巴巴落地实践 Service Mesh 过程中的观察与思考，来和大家进行分享。 Service Mesh 是新瓶装旧酒吗？ 新技术出现时所主张的价值一定会引发相应的探讨，Service Mesh 也不例外。 以往，怀疑 Service Mesh 价值的观点主要有两大类。 第一类 是应用的数量并没有达到一定的规模，在 Service Mesh 增加运维和部署复杂度的情形下，认为所带来的成本和复杂度高于所获得的收益。 从根本上来看，这一类并非真正怀疑 Service Mesh 的价值，而是主张在 Service Mesh 还没有完全成熟和普及的情形下，在未来合适的时机再考虑采纳。当然，我在与外部客户交流时也碰到一些特例，他们即便在应用数很少的情形下，仍希望通过

摘要 Hadoop分布式文件系统（HDFS）设计用来可靠的存储超大数据集，同时以高速带宽将数据集传输给用户应用。 在一个超大集群中，数以千计的服务器直接接触存储器和执行用户应用任务。 通过许多服务器的分布式存储和计算，资源随需求增长的时候仍然可以保持经济性。 我们解释了HDFS架构，同时介绍了我们在雅虎使用HDFS去管理25PB企业数据的经验。 1、介绍和相关工作 Hadoop 的 一个重要特点是将数据和计算能力划分为小部分，通过许多（数千）主机运行 ，这些主机并行计算得到他们的结果。一个 Hadoop 集群通过简单增加商用服务器的数量来扩展其计算能力，存储能力和 IO 带宽。 1.1、与其他分布式系统的异同点 相同点 HDFS 分别存储文件系统元数据和应用程序数据。 与在 其他分布式文件系统 中相同， 比如 PVFS 【 2 】【 14 】， Lustre 【 7 】和 GFS 【 5 】【 8 】， HDFS 在一个专门的服务器存储元数据，这个服务器被称为名称节点。应用程序数据存储在其他被称为数据结点的服务器上。 不同点 HDFS中的数据节点 并不使用数据保护机制 比如RAID（ 独立磁盘冗余阵列 ），以确保数据持久性。 相反。比如GFS， 其文件内容在多个数据节点是重复的以确保可靠性 。 这个策略不仅仅可以确保数据持久性，还有额外的优点：数据变形带宽加倍

Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一个分布式的，可划分的，冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。 在大数据系统中，常常会碰到一个问题，整个大数据是由各个子系统组成，数据需要在各个子系统中高性能，低延迟的不停流转。传统的企业消息系统并不是非常适合大规模的数据处理。为了已在同时搞定在线应用（消息）和离线应用（数据文件，日志）Kafka就出现了。Kafka可以起到两个作用： 降低系统组网复杂度。 降低编程复杂度，各个子系统不在是相互协商接口，各个子系统类似插口插在插座上，Kafka承担高速数据总线的作用。 1、Kafka主要特点： 同时为发布和订阅提供高吞吐量。据了解，Kafka每秒可以生产约25万消息（50 MB），每秒处理55万消息（110 MB）。 可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication防止数据丢失。 分布式系统，易于向外扩展。所有的producer、broker和consumer都会有多个，均为分布式的。无需停机即可扩展机器。 消息被处理的状态是在consumer端维护，而不是由server端维护。当失败时能自动平衡。 支持online和offline的场景。 2、Kafka的架构