分布式部署

文章原创于公众号：程序猿周先森。本平台不定时更新，喜欢我的文章，欢迎关注我的微信公众号。 在实际项目开发中经常会遇到这样一个业务场景：如果同一台机器有多个线程抢夺同一个共享资源，同一个线程多次执行会出现异常，这种情况下就会出现非线程安全。我们解决方法通常使用锁来解决。但是如果有多台机器呢？这时候我们通常使用分布式锁来解决分布式环境下共享资源的同步问题。实现分布式锁常见有Redis，zookeeper等，今天主要就是讲讲如何使用Redis实现分布式锁。 使用Redis实现分布式锁的方案其实很简单，首先我们先实现一个方案一：每次执行请求的时候，机器先查询Redis中是否存在分布式锁的key，如果不存在锁的key，就以该锁为key，value取随机数写入到Redis中，然后开始执行请求。 方案一看起来很简单，但是这样的处理逻辑不可避免的存在两个致命的BUG：第一：如果一个进程成功取到锁，但是这时候这个机器出现故障宕机了，分布式的锁没有得到释放，就造成了死锁的产生了。第二：如果同一时间存在两个机器同时查询Redis，都发现Redis不存在锁的key，于是都成功获得了锁。 这时候我们可以这么处理改善方案一实现方案二：Redis有提供一个原子写入操作的命令：setnx，setnx只有在锁的key不存在的情况下才允许设置key值

本文主要介绍分布式任务调度平台XXL-JOB(v2.1.0版本)，包括功能特性、实现原理、优缺点、同类框架比较等 基本介绍 项目开发中，常常以下场景需要分布式任务调度： 同一服务多个实例的任务存在互斥时，需要统一协调 定时任务的执行需要支持高可用、监控运维、故障告警 需要统一管理和追踪各个服务节点定时任务的运行情况，以及任务属性信息，例如任务所属服务、所属责任人 因此，XXL-JOB应运而生： XXL-JOB是一个开源的轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展、开箱即用，其中“XXL”是主要作者，大众点评 许雪里 名字的缩写 自2015年开源以来，已接入数百家公司的线上产品线，接入场景涉及电商业务，O2O业务和大数据作业等 功能特性 主要功能特性如下： 简单灵活 提供Web页面对任务进行管理，管理系统支持用户管理、权限控制； 支持容器部署； 支持通过通用HTTP提供跨平台任务调度； 丰富的任务管理功能 支持页面对任务CRUD操作； 支持在页面编写脚本任务、命令行任务、Java代码任务并执行； 支持任务级联编排，父任务执行结束后触发子任务执行； 支持设置任务优先级； 支持设置指定任务执行节点路由策略，包括轮询、随机、广播、故障转移、忙碌转移等； 支持Cron方式、任务依赖、调度中心API接口方式触发任务执行 高性能

当多个进程在不同的系统中，就需要使用分布式锁控制多个进程对同一个资源的访问。本篇介绍的是通过 Redis 实现的分布式锁。 为了确保分布式锁的可用性，我们至少要确保锁的实现同时满足以下四个条件： 互斥性； 不会发生死锁，即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁； 具有容错性，只要大部分的 Redis 节点正常运行，客户端就可以加锁和解锁； 加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。 分布式锁实现方案： 数据库乐观锁； 通过 Redis 实现分布式锁，利用 Redis 的 setnx 命令来实现分布式锁； 通过 Zookeeper 实现分布式锁，利用 Zookeeper 的顺序临时节点实现分布式锁和等待队列； 优缺点： 分布式锁 优点 缺点 Redis set 和 del 指令的性能较高。 1、实现复杂，需要考虑超时、原子性、误删等情况； 2、没有等待的队列，只能在客户端自旋来等锁，效率低下。 Zookeeper 1、有封装好的框架，容易实现； 2、有等待锁的队列，大大提升抢锁效率。 添加和删除节点性能较低。 通过 Redis 实现分布式锁的流程图： 占用 不占用 访问资源 获得锁 判断锁是否被占用 等待释放 创建key 当前线程拥有该锁 释放锁,即删除key Redis 没有等待锁的队列，只能在客户端自旋来等锁。这里

概述 本文介绍使用ELK（elasticsearch、logstash、kibana） +　kafka来搭建一个日志系统。主要演示使用spring aop进行日志收集，然后通过kafka将日志发送给logstash，logstash再将日志写入elasticsearch，这样elasticsearch就有了日志数据了，最后，则使用kibana将存放在elasticsearch中的日志数据显示出来，并且可以做实时的数据图表分析等等。 详细 代码下载： http://www.demodashi.com/demo/10181.html 本文介绍使用ELK（elasticsearch、logstash、kibana） +　kafka来搭建一个日志系统。主要演示使用spring aop进行日志收集，然后通过kafka将日志发送给logstash，logstash再将日志写入elasticsearch，这样elasticsearch就有了日志数据了，最后，则使用kibana将存放在elasticsearch中的日志数据显示出来，并且可以做实时的数据图表分析等等。 为什么用ELK 以前不用ELK的做法 最开始我些项目的时候，都习惯用log4j来把日志写到log文件中，后来项目有了高可用的要求，我们就进行了分布式部署web，这样我们还是用log4j这样的方式来记录log的话

简介 　　Apache Thrift是Facebook开源的跨语言的RPC通信框架，目前已经捐献给Apache基金会管理，由于其跨语言特性和出色的性能，在很多互联网公司得到应用，有能力的公司甚至会基于thrift研发一套分布式服务框架，增加诸如服务注册、服务发现等功能。 　　RPC即Remote Procedure Call，翻译为远程过程调用。任何RPC协议的实现终极目标都是让使用者在调用远程方法的时候就像是调用本地方法一样简单，从而提高使用远程服务的效率。 　　现代互联网架构多数基于SOA思想而搭建，即面向服务化的架构。服务提供方称为Provider，服务的使用方称为Consumer，有时也把服务提供方称为Server端，使用方称为Client端，即典型的CS模型。这里的远程调用，主要指跨进程的调用，Provider和Consumer可能是同一机器的不同进程，也可能在不同的机器，通过网络相互通信，大部分情况下两者会部署在不同的物理机器上，这种情况下由于网络通信的开销就会对RPC框架的性能要求极高。 下面分别从服务端和客户端的视角来介绍Thrift在RPC中的应用。 服务端(Server) 服务端需要发布一个服务给别人使用，首先要约定好服务的接口，包括以下几个部分： 服务的名称 服务使用时的参数 返回结果 Thrift自己规定了一套接口定义语言（IDL）来描述服务，用后缀为

redis分布式部署 - 概念：可以将一组程序执行在多台机器上（分布式机群），使其进行数据的分布爬取。 1.scrapy框架是否可以自己实现分布式？ 　　　　　　其一：因为多台机器上部署的scrapy会各自拥有各自的调度器，这样就使得多台机器无法分配start_urls列表中的url。（多台机器无法共享同一个调度器） 　　　　　　其二：多台机器爬取到的数据无法通过同一个管道对数据进行统一的数据持久出存储。（多台机器无法共享同一个管道） 2.基于scrapy-redis组件的分布式爬虫 - scrapy-redis组件中为我们封装好了可以被多台机器共享的调度器和管道，我们可以直接使用并实现分布式数据爬取。 - 实现方式： 1.基于该组件的RedisSpider类 2.基于该组件的RedisCrawlSpider类 3.分布式实现流程：上述两种不同方式的分布式实现流程是统一的 - 3.1 下载scrapy-redis组件：pip install scrapy-redis - 3.2 redis配置文件的配置： 　　- 注释该行：bind 127.0.0.1，表示可以让其他ip访问redis 　　- 将yes该为no：protected-mode no，表示可以让其他ip操作redis 3.3 修改爬虫文件中的相关代码： -

1、ZooKeeper介绍与核心概念 1.1 简介 ZooKeeper最为主要的使用场景，是作为分布式系统的分布式协同服务。在学习zookeeper之前，先要对分布式系统的概念有所了解，否则你将完全不知道zookeeper在分布式系统中起到了什么作用，解决了什么问题。 1.2分布式系统面临的问题 我们将分布式系统定义为：分布式系统指的是同时跨越多个物理主机，将一个完整的系统划分为多个独立运行的子系统，这些子系统之间互相协作构成一个完整的系统功能。类比一下，分布式系统就是将一个完整的任务细分为多个子任务，一群人分别完成一个子任务，最终完成整个任务。人多力量大，每个服务器的算力是有限的，但是通过分布式系统，由n个服务器组成起来的集群，算力是可以无限扩张的。 说起分布式就要谈谈集群，两者很相似，都是通过网络协同多台主机服务器节点完成整体的功能。 但不同点在于： 集群中的每个服务器节点都完成的是同一个功能，比如mysql数据库集群、redis集群； 而分布式系统则是各个服务器节点所负责的是不同的子系统（任务或者说功能），比如电商系统的分布式系统会分为订单系统、支付系统、数据库系统、缓存系统等等。 所谓分布式集群系统，就是将一个完整的系统进行拆分多个子系统，每个子系统都进行集群部署，各系统集群之间互相协作，就能构成一个分布式集群系统。 优点显而易见，人多干活快，并且互为备份。但是缺点也很明显

##2.1 网站架构模式## 为了解决大型网站面临的高并发访问，海量数据处理，高可靠运行等一系列问题与挑战，大型互联网公司在实践中提出了许多解决方案，以实现网站高性能，高可用，易伸缩，可扩展，安全等各种技术架构目标。这些解决方案又被更多网站重复使用，从而逐渐形成大型网站架构模式。 ###2.1.1 分层### 分层是企业应用系统中最常见的一种架构模式，将系统在 横向维度 上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。 分层结构在计算机世界中无处不在， 网络的7层通信协议 是一种分层结构；计算机硬件，操作系统，应用软件也可以看作是一种分层结构。在大型网站中也采用分层结构，将网站软件系统分为 应用层 ， 服务层 ， 数据层 ，如下： 应用层 ：负责具体业务和视图展示，如网站首页及搜索输入和结果展示； 服务层 ：为应用层提供服务支持，如用户管理服务，购物车服务等； 数据层 ：提供数据存储访问服务，如数据库，缓存，文件，搜索引擎等； 通过分层，可以更好地将一个庞大的软件系统切分成不同的部分，便于分工合作开发和维护；各层之间具有一定的独立性，只要维持调用接口不变，各层可以根据具体问题独立演化发展而不需要其他层必须做出相应调整。 但是分层架构也有一些挑战，就是 必须合理规划层次边界和接口 ，在开发过程中，严格遵循分层架构的约束

.NET Core针对缓存提供了很好的支持 ，我们不仅可以选择将数据缓存在应用进程自身的内存中，还可以采用分布式的形式将缓存数据存储在一个“中心数据库”中。对于分布式缓存，.NET Core提供了针对Redis和SQL Server的原生支持。除了这个独立的缓存系统之外，ASP.NET Core还借助一个中间件实现了“响应缓存”，它会按照HTTP缓存规范对整个响应实施缓存。不过按照惯例，在对缓存进行系统介绍之前，我们还是先通过一些简单的实例演示感知一下如果在一个ASP.NET Core应用中如何使用缓存。 目录 一、将数据缓存在内存中 二、基于Redis的分布式缓存 三、基于SQL Server的分布式缓存 四、缓存整个HTTP响应 一、将数据缓存在内存中 与针对数据库和远程服务调用这种IO操作来说，应用针对内存的访问性能将提供不止一个数量级的提升，所以将数据直接缓存在应用进程的内容中自然具有最佳的性能优势。与基于内存的缓存相关的应用编程接口定义在NuGet包“Microsoft.Extensions.Caching.Memory”中，具体的缓存实现在一个名为MemoryCache的服务对象中，后者是我们对所有实现了IMemoryCache接口的所有类型以及对应对象的统称。由于是将缓存对象直接置于内存之中，中间并不涉及持久化存储的问题，自然也就无需考虑针对缓存对象的序列化问题

详尽的视频讲解，请查看该地址： https://edu.csdn.net/course/detail/9572 1.集群规划 1.1主机规划 前面的文章中，我们已经搭建了一个3节点的Hadoop分布式集群，为了保证数据的本地性，HBase集群与Hadoop集群共用节点。 1.2软件规划 前面hadoop集群使用的安装包为hadoop-2.6.0-cdh5.10.0.tar.gz，这里选择与Hadoop相兼容的hbase-1.2.0-cdh5.10.0.tar.gz安装包 1.3用户与用户组规划 安装HBase用户和用户组跟Hadoop集群保持一致即可。 1.4目录规划 安装HBase分布式集群，默认配置文件有一些默认的日志目录和进程目录，为了方便管理，我们规划好自己创建目录，便于统一管理。 2.HBase分布式集群安装 2.1下载 CDH版本：http://archive-primary.cloudera.com/cdh5/cdh/5/ 这里选择下载hbase-1.2.0-cdh5.10.0.tar.gz版本的安装包，上传至主节点/home/hadoop/app目录。 2.2解压 使用如下命令解压HBase安装包： tar -zxvf hbase-1.2.0-cdh5.10.0.tar.gz 2.3创建软连接 为了方便操作，使用如下命令创建软连接： ln -s hbase-1.2