Author name: Vinny Wang

一、前言 前一篇已经详细的讲解了Zookeeper的Leader选举过程，下面接着学习Zookeeper中服务器的各个角色及其细节。 二、服务器角色 2.1 Leader Leader服务器是Zookeeper集群工作的核心，其主要工作如下 (1) 事务请求的唯一调度和处理者，保证集群事务处理的顺序性。 (2) 集群内部各服务器的调度者。 1. 请求处理链 使用责任链来处理每个客户端的请求时Zookeeper的特色，Leader服务器的请求处理链如下 (1) PrepRequestProcessor。请求预处理器。在Zookeeper中，那些会改变服务器状态的请求称为事务请求（创建节点、更新数据、删除节点、创建会话等），PrepRequestProcessor能够识别出当前客户端请求是否是事务请求。对于事务请求，PrepRequestProcessor处理器会对其进行一系列预处理，如创建请求事务头、事务体、会话检查、ACL检查和版本检查等。 (2) ProposalRequestProcessor。事务投票处理器。Leader服务器事务处理流程的发起者，对于非事务性请求，ProposalRequestProcessor会直接将请求转发到CommitProcessor处理器，不再做任何处理，而对于事务性请求，处理将请求转发到CommitProcessor外，还会根据请求类型创建对应的Proposal提议，并发送给所有的Follower服务器来发起一次集群内的事务投票。同时，ProposalRequestProcessor还会将事务请求交付给SyncRequestProcessor进行事务日志的记录。 (2) SyncRequestProcessor。事务日志记录处理器。用来将事务请求记录到事务日志文件中，同时会触发Zookeeper进行数据快照。 (3) […]

一、前言 前面学习了Zookeeper服务端的相关细节，其中对于集群启动而言，很重要的一部分就是Leader选举，接着就开始深入学习Leader选举。 二、Leader选举 2.1 Leader选举概述 Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。 (1) 服务器初始化启动。 (2) 服务器运行期间无法和Leader保持连接。 下面就两种情况进行分析讲解。 1. 服务器启动时期的Leader选举 若进行Leader选举，则至少需要两台机器，这里选取3台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下 (1) 每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。 (2) 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。

总体思路 这个涉及到两个方面问题： 一个是接口访问认证问题,主要解决谁可以使用接口（用户登录验证、来路验证） 一个是数据数据传输安全,主要解决接口数据被监听（HTTPS安全传输、敏感内容加密、数字签名） 用户身份验证：Token与Session 开放接口Api服务其实就是客户端与服务端无状态交互的一种形式，这有点类似REST(Representational State Transfer)风格。 普通网站应用一般使用session进行登录用户信息的存储和验证（有状态），而开放接口服务/REST资源请求则使用Token进行登录用户信息的验证（无状态）。Token更像是一个精简版的session。Session主要用于保持会话信息，会在客户端保存一份cookie来保持用户会话有效性，而Token则只用于登录用户的身份鉴权。所以在移动端使用Token会比使用Session更加简易并且有更高的安全性，同时也更加符合RESTful中无状态的定义。 Token交互流程 客户端通过登录请求提交用户名和密码，服务端验证通过后生成一个Token与该用户进行关联，并将Token返回给客户端。 客户端在接下来的请求中都会携带Token，服务端通过解析Token检查登录状态。 当用户退出登录、其他终端登录同一账号、长时间未进行操作时Token会失效，这时用户需要重新登录。 Token生成原理 服务端生成的Token一般为随机的非重复字符串，根据应用对安全性的不同要求，会将其添加时间戳（通过时间判断Token是否被盗用）或url签名（通过请求地址判断Token是否被盗用）后加密进行传输。一般Token内容包含有：用户名/appid，密码/appsecret, 授权url，用户自定义token(用户自定义签名)，时间戳，有效期时长(秒), 系统签名(sign)等。 Api接口服务调用流程： 1. 首先要获取全局唯一的接口调用凭据(access_token)。该过程务必使用https安全传输协议，否则被拦截监听了，用户名和密码等重要数据就都泄漏了。

常用认证方式 在之前的文章REST API 安全设计指南与使用 AngularJS & NodeJS 实现基于 token 的认证应用两篇文章中，[译]web权限验证方法说明中也详细介绍，一般基于REST API 安全设计常用方式有： HTTP Basic Basic admin:admin Basic YWRtaW46YWRtaW4= Authorization: Basic

REST API 安全设计指南   REST API 安全设计指南。REST的全称是REpresentational State Transfer，它利用传统Web特点，提出提出一个既适于客户端应用又适于服务端的应用的、统一架构，极大程度上统一及简化了网站架构设计。 目前在三种主流的Web服务实现方案中，REST模式服务相比复杂的SOAP和XML-RPC对比来讲，更加简洁，越来越多的web服务开始使用REST设计并实现。但其缺少安全特性，《REST API 安全设计指南》就是一个REST API安全设计的指南，权当抛砖引玉，推荐网站后台设计及网站架构师们阅读。 文章目录 1，REST API 简介 2，身份认证 2.1 HTTP

作者：胡建华 中国移动苏州研发中心，IT支撑产品部，技术研究员 主要从事集中化系统架构设计，以及数据保护（存储、备份、云盘）、智能运维相关领域的技术研究和开发工作。 1、BAIOPS-业务智能运维 智能运维（AIOps-Algorithmic IT Operations基于算法的IT运维）是人工智能技术在IT运维领域的运用，引用Gartner 的报告的一段话“到2020年，将近50%的企业将会在他们的业务和IT运维方面采用AIOps，远远高于今天的10%”，最近2-3年智能运维的概念随处可见，各大互联网公司、传统IT公司、金融业等都在谈他们的智能运维设想，同时也有人谈AI色变，觉得人工智能只是一个愿景，要落地很难。其实AI已经不是一个新的概念了，百度、微软、谷歌等公司早就在10几年前开始自己的人工智能布局了，到现在均已成为人工智能行业的领跑者了。 话不多说，人工智能那么强大，应用场景十分的广泛，当然也包括运维领域，而且面向业务的运维更是运维发展的热点趋势，下面我就和大家就“面向业务的智能运维体系建设的探索与实践”这个话题发表下我的个人见解。   2、传统运维-痛之又痛   传统的运维中，存在着诸多痛点： （1）被动低效的运维难以保证业务连续性 运维人员往往扮演着事后“救火”的角色，待事故发生后才去处理； 数据分散在多处，出了故障无法快速修复，业务连续性难以有效保障； 随着业务复杂性不断提高，人工运维的成本呈指数级增长。 （2）缺乏统一的运维监控体系和技术工具 针对不同运维实体的烟囱式的运维工具，功能重叠、难以整合； 运维的自动化程度偏低，运维脚本泛滥，层次化、模块化程度不足；

本文是学习大型分布式网站架构的技术总结，对构建一个高性能、高可用、可伸缩及可扩展的分布式网站进行了概要性描述，并给出一个架构参考。 文中一部分为读书笔记，一部分是个人经验总结，对大型分布式网站架构有较好的参考价值。 大型分布式网站架构技术 大型网站的特点 大型网站一般有如下特点： 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络攻击 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 大型网站架构目标 大型网站的架构目标有如下几个： 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 扩展性：方便地通过新增/移除方式，增加/减少新的功能/模块。 安全性：提供网站安全访问和数据加密、安全存储等策略。

1、背景 最近公司需要用到Docker，各种包依赖问题，由于在公司内网，下载了一串还有一串，难受。之前已经搭了一个centos7.3的本地yum源，可现在用的7.4，一些包没法用，继续搭一个呗。这是搭建局域网yum源的：http://www.cnblogs.com/nidey/p/6200685.html。中间出了个问题，根目录满了，百度一看都是增加磁盘，不想增加磁盘，我空间够啊，想着法扩一下吧。进入这个问题的正题。 2、知识 参考linux公社的一篇文章：http://www.linuxidc.com/Linux/2014-10/107697.htm 2.1   LVM是 Logical Volume Manager（逻辑卷管理）的简写，它是Linux环境下对磁盘分区进行管理的一种机制，它由Heinz Mauelshagen在Linux 2.4内核上实现。 2.2   物理存储介质（Physical Storage Media） 指系统的物理存储设备：磁盘，如：/dev/hda、/dev/sda等，是存储系统最底层的存储单元。 2.3  物理卷（Physical Volume，PV） 指磁盘分区或从逻辑上与磁盘分区具有同样功能的设备（如RAID），是LVM的基本存储逻辑块，但和基本的物理存储介质（如分区、磁盘等）比较，却包含有与LVM相关的管理参数。

https://blog.csdn.net/xuemoyao/article/details/14002209 概述 关于数据同步主要有两个层面的同步，一是通过后台程序编码实现数据同步，二是直接作用于数据库，在数据库层面实现数据的同步。通过程序编码实现数据同步，其主要的实现思路很容易理解，即有就更新，无则新增，其他情况日志记录，就不做过多的介绍，这里主要讲述的是第二个层面的数据同步，即在数据库层面实现数据同步。 数据库层面的数据库同步主要有三种方式：通过发布/订阅的方式实现同步，通过SQL JOB方式实现数据同步，通过Service Broker 消息队列的方式实现数据同步。 下面分别就这三种数据同步方式，一一详解。 1.    通过发布/订阅的方式实现同步 发布/订阅是Sql Server自带的一种数据库备份的机制，通过该机制可以快速的实现数据的备份同步，不用编写任何的代码。 此种数据同步的方式存在的以下的一些问题： 表结构不能更改，同步双方的表结构必须一致，一旦表结构发生更改需要重新生成数据库快照。 对于大数据量的同步没有可靠的保证。 网络不稳定的情况下同步也不能保证。 总的来说，这种数据备份同步的方式，在表结构一致、数据量不是特别大的情况下还是非常高效的一种同步方式。 网上有很多的关于如何使用发布/订阅的方式实现数据同步的操作示例，这里就不再重复的演示了，有兴趣想要了解的朋友可以参考下面这篇文章： http://kb.cnblogs.com/page/103975/ 2.   

2017年已过去一半，在此小编为大家精心整理了2017上半年热点事件解析、实战技术资料以及特别策划短视频系列，希望可以帮助大家更深入地回顾上半年的技术热点，并储备更充足的技术干粮继续2017的下一半。 我有几张阿里云幸运券分享给你，用券购买或者升级阿里云相应产品会有特惠惊喜哦！把想要买的产品的幸运券都领走吧！快下手，马上就要抢光了。 PART 1 峰会回顾资料 云栖大会 【上海云栖大会】2017云栖大会上海峰会资料合计（现场视频+PDF下载） 【成都云栖大会】2017云栖大会成都峰会资料合计（现场视频+PDF下载） 【南京云栖大会】2017云栖大会南京峰会资料合计（现场视频+PDF下载） 技术峰会 【运维/DevOps峰会】 同城容灾架构剖析 视频回顾  PDF下载 阿里云专家谈DevOPS 视频回顾 PDF下载 云数据库安全实践  视频回顾 PDF下载 饿了么Redis Cluster集群演进 视频回顾 PDF下载 开源DevOps工具云上自动运维 视频回顾 PDF下载 企业上云安全加固最佳实践 视频回顾 PDF下载 构建通用智能运维平台 视频回顾 PDF下载