分布式技术

分布式协调服务 ( 服务治理 ). 1. 问题所在 主要用于解决分布式环境中多个进程之间的同步控制, 让他们有序的去访问某种临界资源, 防止造成脏数据的后果. 订单服务JVM1->商品服务(库存五个): 我要五个 订单服务JVM2->商品服务(库存五个): 我要五个 订单服务JVM3->商品服务(库存五个): 我要五个 商品服务(库存五个)-->订单服务JVM1:给你五个 商品服务(库存五个)-->订单服务JVM2:给你五个 商品服务(库存五个)-->订单服务JVM3:给你五个 这个时候就造成了脏数据的问题, 库存变成了 \(-10\) 个 2. 解决方案 分布式锁: 在第一个订单服务访问到商品服务的时候, 我们将商品服务加锁. 这个时候 第二个订单服务去访问 商品服务的时候会被拒绝. 分布式协调的核心就是 实现分布式锁, 而Zookeeper就是分布式锁的实现框架. 分布式锁 1. 目的 为了防止分布式系统中的多个进程之间的相互干扰, 我们需要一种分布式协调技术去对这些进程进行调度, 而这个分布式协调技术的核心就是来实现这个分布式锁, 而Zookeeper 就是分布式锁的实现框架 . 2. 完备条件 在分布式系统环境下, 一个方法在同一时间只能被一个机器的一个线程执行. 高可用的获取锁和释放锁. 高性能的获取锁和释放锁. 具备非阻塞特性 , 即没有获取到锁将直接放回获取锁失败.

Redis数据量日益增大，使用的公司越来越多，不仅用于做缓存，同时趋向于存储这一块，这样必促使集群的发展，各个公司也在收集适合自己的集群方案，目前行业用的比较多的是下面几种集群架构，大部分都是采用分片技术，保证单实例内存增大带来的一系列问题，下面所列出的codis方案目前正在不断测试过程中，测试过程没有展示出来，主要从以下几点出发。 测试架构 和性能 ： 　　1、keepalived+haproxy故障测试 　　2、Zookeeper集群节点测试 　　3、Codis-proxy集群节点测试 　　4、Codis-server集群节点测试 　　5、脚本写入大量测试数据并模拟数据迁移 　　6、性能测试 下面具体介绍codis和其他几大集群方案 集群方案： 　　1、 主从高可用（该方案就是单实例形式，只是为了保证数据的安全，对于用户数据少，业务的前期可以采用，目前我司缓存架构就是采用该方案） 　　2、 客户端分片（典型代表：Jedis。自主写分片算法，代码掌握在自己手中，可控性强，但是需要专业的开发运维人员维护，技术要求和维护成本高） 　　3、代理分片（典型代表：Twemproxy，redis集群没有正式推出之前官网推荐的方案，也是目前使用最多的） 　　4、 Redis cluster（3版本推出的集群方案，历时四年之多的开发） 　　5、 Codis集群（豌豆荚15年开源的解决方案

一、概要 1.分布式安全服务编排概念 2.须弥(Sumeru)关键实现思路 3.应用场景 二、前言 在笔者看来，安全防御的本质之一是增加攻击者的攻击成本，尤其是时间成本。那么从防御的角度来说，如何尽早和及时地发现潜在的安全风险变得尤为重要，因此安全扫描对时效性要求很高。在进行自身检测的同时，数以万计攻击者也在时刻探测着你的安全风险。乐观者可能不以为然，但事实上做安全就是木桶原理，短板是攻击者的首选。如果加上验证程序开发和落地的时间开销，可能又会造成一定的发现时延。有时候出了问题，就要与时间赛跑，及时避损或止损。 另外，分布式技术一直以来被用于解决单机性能瓶颈，而且像漏洞扫描器这类安全产品开发者对分布式这个概念也一直有着很深的执念，因为在漏报率和误报率达到某种瓶颈之后，扫描速度成为了另外一个突破口。 安全扫描周期较长也是我们在之前实际工作中遇到的痛点，加上安全防御是整个面而不是单个点，所以想要形成面，需求真的是不要太多，所以扫描工具研发和运维成本较高的问题也同样令人头秃，借此，本文为大家介绍宜信安全团队应用分布式安全服务编排的实践经验，虽说依然存在许多不足之处，但也达成了不少预期效果，总之，希望大家能有所收获或参考。 三、需求简述 3.1 缩短安全扫描周期 举例：端口扫描周期较长，目标：10000+个IP ，全端口+服务指纹扫描，从7小时优化到30分钟内。Masscan

引言 本文通过对卷类型的分析对比，来帮助读者选取生产环境最符合服务的挂载存储，命令可结合《 glusterfs详解及kubernetes 搭建heketi-glusterfs 》进行实验，下面进入正题 几种卷类型 基础卷：布式卷（distribute）、条带卷（stripe）、复制卷（replica）、纠错卷（Dispersed ） 复合卷：分布式条带卷（distribute stripe）、分布式复制卷（distribute replica）、条带复制卷（stripe replica）、分布式条带复制卷（distribute stripe） 一、基础卷 以下创建挂载卷，均可通过以下命令进行查看、启用、停止、删除 #查看已创建挂载卷 gluster volume info #启动挂载卷 gluster volume start gv0 #删除前，先停止挂载卷 gluster volume stop gv0 #删除挂载卷 gluster volume delete gv0 1. 布式卷（distribute voulme） 分布式模式，既DHT，是GlusterFS的默认模式，在创建卷时，默认选项是创建分布式卷。在该模式下，并没有对文件进行分块处理，而是通过hash算法分布到所有brick server上，只是扩大了磁盘空间，类似window中的跨区卷 distribute

在科技的快速发展推动下，在IT领域，企业会面临两个方面的问题。 一是如何实现网站的高可用、易伸缩、可扩展、高安全等目标。为了解决这样一系列问题，迫使网站的架构在不断发展。从单一架构迈向高可用架构，这过程中不得不提的就是分布式。 二是用户规模越来越大，由此产生的数据也在以指数倍增长，俗称数据大爆炸。海量数据处理的场景也越来越多。技术上该如何面对？ 1． 分布式系统1.1． 概述 分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。简单来说就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。 分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。 初代的web服务网站架构往往比较简单，应用程序、数据库、文件等所有的资源都在一台服务器上。 图：互联网初始阶段的网站架构 图：现在互联网网站常用的架构 从分布式系统的概念中我们知道，各个主机之间通信和协调主要通过网络进行，所以，分布式系统中的计算机在空间上几乎没有任何限制，这些计算机可能被放在不同的机柜上，也可能被部署在不同的机房中，还可能在不同的城市中，对于大型的网站甚至可能分布在不同的国家和地区。 1.2． 特征 分布性

用一web应用集群，负载均衡部署实现： 在上图可以看到，变量A在JVM1、JVM2、JVM3三个JVM内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果我们不加任何控制的话，变量A同进都会在JVM分配一块内存，三个请求发过来同时对这个变量进行操作，显然结果不是我们想要的。 如果我们业务中存在这样的场景的话，就需要找到一种方法来解决。 为了保证一个方法或属性在高并发的情况下同一时间只能被同一个线程执行，在传统单机部署的情况下，可以使用Java并发处理相关的API（如 ReentrantLock 或 Synchronized ）进行互斥控制。但是，随之业务发展的需要，原单机部署的系统演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同的机器上，这将原来的单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。 为了解决这个问题，就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！ 分布式锁应该具备哪些条件 在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行； 高可用、高性能的获取锁与释放锁； 具备可重入特性； 具备锁失效机制、防止死锁； 具备非阻塞锁特性，即没有获取到锁直接返回获取锁失败； 分布式锁的实现方式 目前几乎所有大型网站及应用都是分布式部署

看到分布式、高并发、多线程这三个词的时候，很多人是不是都认为分布式=高并发=多线程？ 当面试官问到高并发系统可以采用哪些手段来解决，或者被问到分布式系统如何解决一致性的问题，是不是一脸懵逼？ 确实，在一开始接触的时候，不少人都会分布式、高并发、多线程将三者混淆，误以为所谓的分布式高并发的系统就是能同时供海量用户访问，而采用多线程手段不就是可以提供系统的并发能力吗？实际上，他们三个总是相伴而生，但侧重点又有不同。 接下来我就看看分布式、高并发、多线程这三者之间到底有什么区别？ 什么是分布式？ 分布式更多的一个概念，是为了解决单个物理服务器容量和性能瓶颈问题而采用的优化手段。该领域需要解决的问题极多，在不同的技术层面上，又包括：分布式文件系统、分布式缓存、分布式数据库、分布式计算等，一些名词如Hadoop、zookeeper、MQ等都跟分布式有关。从理念上讲，分布式的实现有两种形式： 水平扩展：当一台机器扛不住流量时，就通过添加机器的方式，将流量平分到所有服务器上，所有机器都可以提供相当的服务； 垂直拆分：前端有多种查询需求时，一台机器扛不住，可以将不同的需求分发到不同的机器上，比如A机器处理余票查询的请求，B机器处理支付的请求。 什么是高并发？ 相对于分布式来讲，高并发在解决的问题上会集中一些，其反应的是同时有多少量：比如在线直播服务，同时有上万人观看。

世上本没有坑，挖的人多了，自然就有坑了。 公司最近要搭一个分布式集群来训练数据，作为一个无知而又热爱求知的小白，自然被虐得头发都掉了一地。 花了整整2.5个星期后，终于在开源哥们的指导下才大概估计到原因所在，最后才在华为的一个技术贴上找到答案，那时候真是Duang的一声，看着进程终于跑起来的那一刻，真的是想来个夕阳下的奔跑来庆祝一下。这过程真的不容易啊，期间基本把google和百度的资料不管相关和不相关都翻了个遍，也没有很好解决问题，那时候心态是真的爆炸了，最后改了一下关键字，才在谷歌结果的最后一页看到华为的帖子有那么几个字相关，没想到点开后就打开了新世界，激动!!!!! 扯淡到此为止，现在来介绍一下部署细节。 本部署是基于ubuntu 16.04 + hadoop + spark + tensorflowOnSpark + tensorflow 1.8 这里集群的环境是1个ps和2个worker hadoop和spark部署 hadoop和spark的部署这里不做叙述，网上的资料一大堆，按照来基本上没有问题，有问题的话再找一个其它靠谱的再配，反正最终能运行就可以了。 tensorflow和tensorflowOnSpark安装 这里是采取yarn作为资源管理器，具体安装过程可以参考 官网 。网上很多文章都说官方说明文档简略，但是其实踩完坑后发觉，其实真的就这么简略，跑不起来

| 导语 工欲善其事，必先利其器； 士欲宣其义，必先读其书。 后台开发作为互联网技术领域的掌上明珠，一直都是开发者们的追逐的高峰。 本文将从后台开发所涉及到的技术术语出发，基于系统开发、架构设计、网络通信等几个方面让大家对后台 开 发有一个清晰的了解，讲解全面易懂。 系统开发 1. 高内聚/低耦合 高内聚指一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。 模块的内聚反映模块内部联系的紧密程度。 模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。一个完整的系统，模块与模块之间，尽可能的使其独立存在。 通常程序结构中各模块的内聚程度越高，模块间的耦合程度就越低。 2. 过度设计 过度设计就是进行了过多的面向未来的设计或者说把相对简单的事情想复杂了，过度追求模块化、可扩展性、设计模式等，为系统增加了不必要的复杂度。 3. 过早优化 过早指的不是在开发过程的早期，而是在还没弄清楚需求未来的变化的走向的时候。你的优化不仅可能导致你无法很好地实现新的需求，而且你对优化的预期的猜测有可能还是错的，导致实际上你除了把代码变复杂以外什么都没得到。 正确的方法是， 先有质量地实现你的需求，写够testcase，然后做profile去找到性能的瓶颈，这个时候才做优化。 4. 重构

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