分布式部署

前言 Apache Flink（下简称Flink）项目是大数据处理领域最近冉冉升起的一颗新星，其不同于其他大数据项目的诸多特性吸引了越来越多人的关注。本文将深入分析Flink的一些关键技术与特性，希望能够帮助读者对Flink有更加深入的了解，对其他大数据系统开发者也能有所裨益。本文假设读者已对MapReduce、Spark及Storm等大数据处理框架有所了解，同时熟悉流处理与批处理的基本概念。 文章转载自： 深入理解Flink核心技术 一.Flink简介 Flink核心是一个流式的数据流执行引擎，其针对数据流的分布式计算提供了数据分布、数据通信以及容错机制等功能。基于流执行引擎，Flink提供了诸多更高抽象层的API以便用户编写分布式任务： DataSet API， 对静态数据进行批处理操作，将静态数据抽象成分布式的数据集，用户可以方便地使用Flink提供的各种操作符对分布式数据集进行处理，支持Java、Scala和Python。 DataStream API，对数据流进行流处理操作，将流式的数据抽象成分布式的数据流，用户可以方便地对分布式数据流进行各种操作，支持Java和Scala。 Table API，对结构化数据进行查询操作，将结构化数据抽象成关系表，并通过类SQL的DSL对关系表进行各种查询操作，支持Java和Scala。 此外，Flink还针对特定的应用领域提供了领域库

1)笔记 1)通用服务器 (1)网关服务器 (2)用户服务器 2)系统服务器 3)游戏服务器 4)多服务器启动部署 (1)因为服务器是c++ lua,因此build出来一个exe用于启动lua脚本即可启动 不同的服务器 (2)搜索路径的设置: 共用Stype和Ctype,因此搜索路径设置为scripts/ 下, 因此即使是当前目录,也要加上 "gateway/gw_service" 这样 5)网关服务器的功能 (1)最大的功能是转发: 客户端消息-->服务器 服务器消息-->客户端 (2)网关服务器的优点 a.将整个系统的运算和负载分到不同服务器上,方便扩展 b.千锤百炼的进程不容易挂掉,后面开发的业务进程经常改变,容易出问题, 业务进程挂掉了,玩家还和网关连接着,不会感知的到 c.独立的网关服务器可以分散业务进程的压力,让服务器容纳更多的人; 如果玩家直接去连接业务服务器,只能连接一个,而有网关,则可以转发到 不同的服务器上,提升一组服务器的负载 d.负载均衡和广播消息的负载均衡,因为网关知道哪个服务器有负载等 6)目录调整: (1)进程架构目录: gateway auth_server 或者 account_server talkroom (2)Stype.lua: 标记都有哪些服务器 Auth = 1 System = 2 Logic = 3 (3)Cmd.lua 或

架构的本质 一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最 终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。 架构的本质就是对系统进行有序化重构，使系统不断进化 那架构是如何实现无序到有序的呢？ 基本的手段就是分和合，先把系统打散，然后重新组合。 分的过程是把系统拆分为各个子系统 / 模块 / 组件，拆的时候，首先要解决每个组件的定 位问题，然后才能划分彼此的边界，实现合理的拆分。合就是根据最终要求，把各个分离的 组件有机整合在一起，相对来说，第一步的拆分更难。 拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得 柔性，可以因需而变，实现业务敏捷 架构的分类 架构一般可分业务架构、应用架构、技术架构 1. 业务架构从概念层面帮助开发人员更好的理解系统，比如业务流程、业务模块、输入输出、 业务域 2. 应用架构从逻辑层面帮助开发落地系统，如数据交互关系、应用形式、交互方式，是的整 个系统逻辑上更容易理解，步入大家熟知的 SOA 就属于应用架构的范畴 3. 技术架构主要解决技术平台选型、如操作系统、中间件、设备、多机房、水平扩展、高可 用等问题 需要注意的是，系统或者架构首先都是为人服务的，系统的有序度高，用用逻辑合理，业务 概念清晰是第一位。现在大家讨论更多的是技术架构，如高并发设计

一、缓存概述 缓存是分布式系统中的重要组件，主要解决高并发，大数据场景下，热点数据访问的性能问题。提供高性能的数据快速访问。 1.1缓存的原理 （1） 将数据写入/读取速度更快的存储（设备）； （2） 将数据缓存到离应用最近的位置； （3） 将数据缓存到离用户最近的位置。 1.2缓存分类 在分布式系统中，缓存的应用非常广泛，从部署角度有以下几个方面的缓存应用。 （1） CDN缓存； （2） 反向代理缓存； （3） 分布式Cache； （4） 本地应用缓存； 1.3缓存媒介 常用中间件：Varnish，Ngnix，Squid，Memcache，Redis，Ehcache等； 缓存的内容：文件，数据，对象； 缓存的介质：CPU，内存（本地，分布式），磁盘（本地，分布式） 1.3缓存设计 缓存设计需要解决以下几个问题： （1） 缓存什么？ 哪些数据需要缓存：1.热点数据；2.静态资源； （2） 缓存的位置？ CDN，反向代理，分布式缓存服务器，本机（内存，硬盘） （3） 如何缓存的问题？ 过期策略 1.固定时间：比如指定缓存的时间是30分钟； 2.相对时间：比如最近10分钟内没有访问的数据； 同步机制 实时写入；（推） 异步刷新；（推拉） 二、CDN缓存 CDN主要解决将数据缓存到离用户最近的位置，一般缓存静态资源文件（页面，脚本，图片，视频，文件等）。国内网络异常复杂

今天小编给大家带来StarlingX3.0版本即将发布的重要功能。 分布式云简介 分布式云为地理位置分布的StarlingX系统(kubernetes-only)提供集中管理和编排，从而支持边缘计算解决方案。StarlingX分布式部署旨在满足基于边缘的数据中心的需求，在这些边缘数据中心中，NFC资源本地化可以实现最好的性能和最大的响应能力。同时，管理和控制功能的集中化可以实现高效的管理能力。该系统支持大量可扩展的StarlingX边缘集群，从中心云通过L3网络进行集中管理和同步。每个边缘云同时具有高可扩展性，支持从单一节点的simplex到带有存储节点的标准StarlingX多节点部署方式。 该架构的特点是采用同步的分布式控制平面以减少延迟，边缘云采用自治的控制面，这样即使失去到中心云的北向连接，所有的边缘云本地服务可以正常运行。 分布式云架构 分布式云由一个中心云和一个或多个边缘云组成，边缘云通过L3网络连接中心云的SystemController Region。 中心云 中心云提供用于管理自身的平台和节点的RegionOne 和用于管理和编排边缘云的SystemController RegionOne 管理中心云的平台和节点 SystemController 用于管理边缘云。管理边缘云的全生命周期，同步所有子云之间的配置数据，并监视子云操作和警报

前言 题目有点大，所以不可能说得非常具体，笔者也不能驾驭全部。 前面介绍过 网站发展过程中架构的演化过程 ,本文主要针对网站架构各个方面的建设进行简单介绍。 架构模式 先来说说模式： 每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地用该方案而不必做重复工作 。 先来说说常见的网站架构模式。这里没有涉及具体实现过程，只是简单介绍其思想和原理，方便日后有用到再深入了解。 分层 分层是企业应用系统中最常见的一种架构模式，将系统在 横向维度 上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后 通过上层对下层的依赖和调用 组成一个完整的系统。 分层 功能 应用层 负责具体业务和视图展示，如网站首页以及搜索输入和结果展示 服务层 为应用层提供服务支持，如用户管理服务，购物车服务 数据层 提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等 分层架构 还可以细分下去 ，比如说应用层可以细分为视图层和业务逻辑层。服务层可以细分为数据接口层和逻辑处理层。 分层结构对网站支持高并发向分布式发展至关重要，所以 在网站规模很小的时候就应该采用分层的架构，这样将来网站做大时才能有更好地应对 。 所以说我们在设计一个新项目的架构时，就需要考虑到分层。不能等到日后项目做大了，再重构就耗时耗力了。 分割 上面的分层是将软件在横向方面进行切分，而分割是在

Zookeeper简介 产生背景 当今是个分布式、集群、云计算等名词满天飞的时代。造成这种局面的一个重要因素就是，单一机器的处理能力已经不能满足我们的需求，不得不采用由多台机器组成的服务集群。 服务集群对外提供服务的过程中，可以分解处理压力，在一定程度上打破性能瓶颈，并提高服务的可用性（不会因为一台机器宕机而造成服务不可用）。 假设有三台机器，每台机器跑同样的一个应用程序。然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的，他感觉不到这个系统是一个什么样的架构。那么我们就可以把这种系统称作一个分布式系统。 那么，问题来了： （1）程序的运行往往依赖很多配置文件，比如数据库地址、黑名单控制、服务地址列表等，而且有些配置信息需要频繁地进行动态变更，这时候怎么保证所有机器共享的配置信息保持一致？ （2）如果有一台机器挂掉了，其他机器如何感知到这一变化并接管任务？如果用户激增，需要增加机器来缓解压力，如何做到不重启集群而完成机器的添加？ （3）用户数量增加或者减少，会出现有的机器资源使用率繁忙，有的却空闲，如何让每台机器感知到其他机器的负载状态从而实现负载均衡？ （4）在一台机器上要多个进程或者多个线程操作同一资源比较简单，因为可以有大量的状态信息或者日志信息提供保证，比如两个A和B进程同时写一个文件，加锁就可以实现

先说一下架构，项目采用Maven管理依赖，总共三个项目，一个是接口包common-inter，一个是服务提供者provider，最后一个是服务消费者cunsumer。 common-inter：主要是各类服务的接口，和接口相关的类，比如Bean或者通用工具等。 provider：服务提供者，采用mybaties+spring框架，当然服务本身也可以作为一个MVC项目，只需要加入框架即可。 cunsumer：服务消费者，采用spring+springMVC架构。 项目非分布式部署。 需求：这里做一个简单的注册、列表和查看三个功能。 下图是eclipse中项目结构： 项目搭建完成后，还需要启动zookeeper，zookeeper是用来注册服务的， 下载地址 。 下载完成后，解压。用cmd命令找到解压后的文件夹，打开bin，找到zkServer.cmd，运行（详细步骤请百度，这里不做细讲）。下面是运行截图： 最小化他，切忌不可关闭。回到eclipse，找到接口项目，建立接口 public interface IUserService { public void insert(User user); public User getUserById(Integer id); public List<User> getUsers(); } User.java public class

hadoop安装 #修改主机名 hostnamectl set-hostname hadoop #修改hosts vim /etc/hosts #追加到末尾 10.0.0.11 hadoop 安装必备依赖包 yum -y install openssh* yum -y install man* yum -y install compat-libstdc++-33* yum -y install libaio-0.* yum -y install libaio-devel* yum -y install sysstat-9.* yum -y install glibc-2.* yum -y install glibc-devel-2.* glibc-headers-2.* yum -y install ksh-2* yum -y install libgcc-4.* yum -y install libstdc++-4.* yum -y install libstdc++-4.*.i686* yum -y install libstdc++-devel-4.* yum -y install gcc-4.*x86_64* yum -y install gcc-c++-4.*x86_64* yum -y install elfutils-libelf-0*x86_64* elfutils

　　一个大型稳健成熟的分布式系统的背后，往往会设计众多的支撑组件，将这些支撑系统成为分布式系统的基础设施。进行系统架构设计所依赖的基础设施，还包括分布式协作及配置管理组件、分布式缓存组件、持久化存储组件、分布式消息系统、搜索引擎、以及CDN系统、负载均衡系统、运维自动化系统等，还有实时计算系统、离线计算系统、分布式文件系统、日志收集系统、监控系统、数据仓库等。此处主要讲讲缓存系统组件。 缓存组件层 缓存系统带来的好处： 加速读写。缓存通常是全内存的，比如Redis、Memcache。对内存的直接读写会比传统的存储层如MySQL，性能好很多。由于单台机器的内存资源和承载能力有限，并且如果大量使用本地缓存，也会使相同的数据被不同的节点存储多份，对内存资源造成较大的浪费，因此才催生出了分布式缓存。 降低后端的负载。在高并发环境下，大量的读、写请求涌向数据库，磁盘的处理速度与内存显然不在一个量级，从减轻数据库的压力和提供系统响应速度两个角度来考虑，一般都会在数据库之前加一层缓存。 缓存系统带来的成本： 数据不一致性：在分布式环境下，数据的读写都是并发的，上游有多个应用，通过一个服务的多个部署(为了保证可用性，一定是部署多份的)，对同一个数据进行读写，在数据库层面并发的读写并不能保证完成顺序，也就是说后发出的读请求很可能先完成(读出脏数据) 代码维护成本：加入缓存后