Uncategorized

一、前言 前一篇已经详细的讲解了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) AckRequestProcessor。负责在SyncRequestProcessor完成事务日志记录后，向Proposal的投票收集器发送ACK反馈，以通知投票收集器当前服务器已经完成了对该Proposal的事务日志记录。 (4) CommitProcessor。事务提交处理器。对于非事务请求，该处理器会直接将其交付给下一级处理器处理；对于事务请求，其会等待集群内针对Proposal的投票直到该Proposal可被提交，利用CommitProcessor，每个服务器都可以很好地控制对事务请求的顺序处理。 (5) ToBeCommitProcessor。该处理器有一个toBeApplied队列，用来存储那些已经被CommitProcessor处理过的可被提交的Proposal。其会将这些请求交付给FinalRequestProcessor处理器处理，待其处理完后，再将其从toBeApplied队列中移除。 (6) FinalRequestProcessor。用来进行客户端请求返回之前的操作，包括创建客户端请求的响应，针对事务请求，该处理还会负责将事务应用到内存数据库中去。 2. LearnerHandler 为了保证整个集群内部的实时通信，同时为了确保可以控制所有的Follower/Observer服务器，Leader服务器会与每个Follower/Observer服务器建立一个TCP长连接。同时也会为每个Follower/Observer服务器创建一个名为LearnerHandler的实体。LearnerHandler是Learner服务器的管理者，主要负责Follower/Observer服务器和Leader服务器之间的一系列网络通信，包括数据同步、请求转发和Proposal提议的投票等。Leader服务器中保存了所有Follower/Observer对应的LearnerHandler。…

一、前言 前面学习了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状态的服务器。 (3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下 · 优先检查ZXID。ZXID比较大的服务器优先作为Leader。 · 如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。 对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。…

总体思路 这个涉及到两个方面问题： 一个是接口访问认证问题,主要解决谁可以使用接口（用户登录验证、来路验证） 一个是数据数据传输安全,主要解决接口数据被监听（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安全传输协议，否则被拦截监听了，用户名和密码等重要数据就都泄漏了。 具体过程： a. 客户端向服务端通过https协议发送请求，参数包含用户名、密码、请求类型等 b. 服务端接到请求后，验证用户信息是否正确，如果正确，返回access_token和expires。否则返回errorcode和errmsg。 c. 服务端access_token可以存储在session或者redis等内存数据库中，键名(key)为user_id,键值为access_token。 d. 客户端获得access_token后，保存到file或redis等内存数据库中。不推荐保存到session或数据库中，保存到session数据容易丢失，保存到数据库因为涉及IO读写，性能较低。 2.…

常用认证方式 在之前的文章REST API 安全设计指南与使用 AngularJS & NodeJS 实现基于 token 的认证应用两篇文章中，[译]web权限验证方法说明中也详细介绍，一般基于REST API 安全设计常用方式有： HTTP Basic Basic admin:admin Basic YWRtaW46YWRtaW4= Authorization: Basic YWRtaW46YWRtaW4= 由于HTTP协议是无状态的，所有每次请求都得带上身份信息，基于Http basic验证就是简单的将用户名和密码base64编码放到header中，一般需要HTTPS,安全性较低，实现的方式可以基于代码实现也可以基于web容器配置apache,nginx等web服务器即可实现。 HTTP Digest 摘要认证 digest authentication,服务器端以nonce进行质询，客户端以用户名，密码，nonce，HTTP方法，请求的URI等信息为基础产生的response信息进行认证的方式。 ※ 不包含密码的明文传递…

http://blog.nsfocus.net/rest-api-design-safety/   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 Basic 2.2 API KEY 2.3 Oauth1.0a或者Oauth2 2.4 JWT 3 授权 4 URL过滤…

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

本文是学习大型分布式网站架构的技术总结，对构建一个高性能、高可用、可伸缩及可扩展的分布式网站进行了概要性描述，并给出一个架构参考。 文中一部分为读书笔记，一部分是个人经验总结，对大型分布式网站架构有较好的参考价值。 大型分布式网站架构技术 大型网站的特点 大型网站一般有如下特点： 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络攻击 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 大型网站架构目标 大型网站的架构目标有如下几个： 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 扩展性：方便地通过新增/移除方式，增加/减少新的功能/模块。 安全性：提供网站安全访问和数据加密、安全存储等策略。 敏捷性：随需应变，快速响应。 大型网站架构模式 如上图是大型网站的架构模式： 分层：一般可分为应用层、服务层、数据层、管理层与分析层。 分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页、用户中心。 分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作。 集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问。 缓存：将数据放在距离应用或用户最近的位置，加快访问速度。 异步：将同步的操作异步化。客户端发出请求，不等待服务端响应，等服务端处理完毕后，使用通知或轮询的方式告知请求方。一般指：请求——响应——通知模式。 冗余：增加副本，提高可用性、安全性与性能。…

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相关的管理参数。 2.4  卷组（Volume Group，VG） 类似于非LVM系统中的物理磁盘，其由一个或多个物理卷PV组成。可以在卷组上创建一个或多个LV（逻辑卷）。 2.5  逻辑卷（Logical Volume，LV） 类似于非LVM系统中的磁盘分区，逻辑卷建立在卷组VG之上。在逻辑卷LV之上可以建立文件系统（比如/home或者/usr等）。 参考下图的架构（图来自linux公社）： 3、步骤…

https://blog.csdn.net/xuemoyao/article/details/14002209 概述 关于数据同步主要有两个层面的同步，一是通过后台程序编码实现数据同步，二是直接作用于数据库，在数据库层面实现数据的同步。通过程序编码实现数据同步，其主要的实现思路很容易理解，即有就更新，无则新增，其他情况日志记录，就不做过多的介绍，这里主要讲述的是第二个层面的数据同步，即在数据库层面实现数据同步。 数据库层面的数据库同步主要有三种方式：通过发布/订阅的方式实现同步，通过SQL JOB方式实现数据同步，通过Service Broker 消息队列的方式实现数据同步。 下面分别就这三种数据同步方式，一一详解。 1.    通过发布/订阅的方式实现同步 发布/订阅是Sql Server自带的一种数据库备份的机制，通过该机制可以快速的实现数据的备份同步，不用编写任何的代码。 此种数据同步的方式存在的以下的一些问题： 表结构不能更改，同步双方的表结构必须一致，一旦表结构发生更改需要重新生成数据库快照。 对于大数据量的同步没有可靠的保证。 网络不稳定的情况下同步也不能保证。 总的来说，这种数据备份同步的方式，在表结构一致、数据量不是特别大的情况下还是非常高效的一种同步方式。 网上有很多的关于如何使用发布/订阅的方式实现数据同步的操作示例，这里就不再重复的演示了，有兴趣想要了解的朋友可以参考下面这篇文章： http://kb.cnblogs.com/page/103975/ 2.    通过SQL JOB方式实现数据同步 通过Sql Job定时作业的方式实现同步其基本原理就是通过目标服务器和源服务器的连接，然后通过编写Sql语句，从源服务器中读取数据，再更新到目标服务器。 这种数据同步的方式比较灵活。创建过sql定时作业之后，主要需要执行以下关键的两步。 2.1     创建数据库连接(一般作为定时作业执行的第一步) 不同数据库之间的连接可以通过系统的存储过程实现。下面就直接用一个示例来讲一下如何创建数据库连接。 --添加一个连接 --系统存储过程sp_addlinkedserver…

2017年已过去一半，在此小编为大家精心整理了2017上半年热点事件解析、实战技术资料以及特别策划短视频系列，希望可以帮助大家更深入地回顾上半年的技术热点，并储备更充足的技术干粮继续2017的下一半。 我有几张阿里云幸运券分享给你，用券购买或者升级阿里云相应产品会有特惠惊喜哦！把想要买的产品的幸运券都领走吧！快下手，马上就要抢光了。 PART 1 峰会回顾资料 云栖大会 【上海云栖大会】2017云栖大会上海峰会资料合计（现场视频+PDF下载） 【成都云栖大会】2017云栖大会成都峰会资料合计（现场视频+PDF下载） 【南京云栖大会】2017云栖大会南京峰会资料合计（现场视频+PDF下载） 技术峰会 【运维/DevOps峰会】 同城容灾架构剖析 视频回顾  PDF下载 阿里云专家谈DevOPS 视频回顾 PDF下载 云数据库安全实践  视频回顾 PDF下载 饿了么Redis Cluster集群演进 视频回顾 PDF下载 开源DevOps工具云上自动运维 视频回顾 PDF下载 企业上云安全加固最佳实践 视频回顾 PDF下载 构建通用智能运维平台 视频回顾 PDF下载 【双11技术峰会】 阿里双11背后的网络自动化技 视频回顾 PDF下载 阿里大规模数据计算与处理 视频回顾 PDF下载 在线AI技术在搜索与推荐场景 视频回顾 PDF下载 揭秘阿里虚拟互动实验室 视频回顾 PDF下载 阿里超大规模Docker化之路 视频回顾 PDF下载 双11媒体大屏背后的数据技术 视频回顾 PDF下载 数据赋能商家背后的AI技术 视频回顾 PDF下载 面对双11的前端“极限挑战” 视频回顾 PDF下载 【红包在线技术峰会】…