精华内容
下载资源
问答
  • ZooKeeper一个高可用的分布式数据管理与系统协调框架。基于对Paxos算法的实现,使该框架保证了分布式环境中数据的...值得注意的,ZK并非天生就是为这些应用场景设计的,都后来众多开发者根据其框架的特性,利...

      ZooKeeper是一个高可用的分布式数据管理与系统协调框架。基于对Paxos算法的实现,使该框架保证了分布式环境中数据的强一致性,也正是基于这样的特性,使得ZooKeeper解决很多分布式问题。网上对ZK的应用场景也有不少介绍,本文将结合作者身边的项目例子,系统地对ZK的应用场景进行一个分门归类的介绍。
      值得注意的是,ZK并非天生就是为这些应用场景设计的,都是后来众多开发者根据其框架的特性,利用其提供的一系列API接口(或者称为原语集),摸索出来的典型使用方法。因此,也非常欢迎读者分享你在ZK使用上的奇技淫巧。

    ZooKeeper数据模型


    Zookeeper 会维护一个具有层次关系的数据结构,它非常类似于一个标准的文件系统,如下图:

    这里写图片描述

    Zookeeper 这种数据结构有如下这些特点:

    1. 每个子目录项如 NameService 都被称作为 znode,这个 znode 是被它所在的路径唯一标识,如 Server1 这个 znode 的标识为 /NameService/Server1;
    2. znode 可以有子节点目录,并且每个 znode 可以存储数据,注意 EPHEMERAL 类型的目录节点不能有子节点目录;
    3. znode 是有版本的,每个 znode 中存储的数据可以有多个版本,也就是一个访问路径中可以存储多份数据;
    4. znode 可以是临时节点,一旦创建这个 znode 的客户端与服务器失去联系,这个 znode 也将自动删除,Zookeeper 的客户端和服务器通信采用长连接方式,每个客户端和服务器通过心跳来保持连接,这个连接状态称为 session,如果 znode 是临时节点,这个 session 失效,znode 也就删除了;
    5. znode 的目录名可以自动编号,如 App1 已经存在,再创建的话,将会自动命名为 App2;
    6. znode 可以被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化可以通知设置监控的客户端,这个是 Zookeeper 的核心特性,Zookeeper 的很多功能都是基于这个特性实现的。


    ZooKeeper的应用场景


    Zookeeper 总体结构

    Zookeeper 服务自身组成一个集群(2n+1个服务允许n个失效)。Zookeeper 服务有两个角色,一个是 leader,负责写服务和数据同步,剩下的是 follower,提供读服务,leader 失效后会在 follower 中重新选举新的 leader。Zookeeper 逻辑图如下:

    这里写图片描述
    ZooKeeper 的客户端-服务器架构

    集群特性:

    • 客户端可以连接到每个server,每个server的数据完全相同。
    • 每个follower都和leader有连接,接受leader的数据更新操作。
    • Server记录事务日志和快照到持久存储。
    • 大多数server可用,整体服务就可用。

    Zookeeper特点:

    • 顺序一致性:按照客户端发送请求的顺序更新数据。
    • 原子性:更新要么成功,要么失败,不会出现部分更新。
    • 单一性 :无论客户端连接哪个server,都会看到同一个视图。
    • 可靠性:一旦数据更新成功,将一直保持,直到新的更新。
    • 及时性:客户端会在一个确定的时间内得到最新的数据。

    Zookeeper运用场景:

    这里写图片描述

    下面分别介绍这些应用场景。

    场景一:数据发布与订阅(配置中心)


    典型场景描述(ZK特性,使用方法)

    发布与订阅模型,即所谓的配置中心,顾名思义就是发布者将数据发布到ZK节点上,供订阅者动态获取数据,实现配置信息的集中式管理和动态更新。例如全局的配置信息,服务式服务框架的服务地址列表等就非常适合使用。

    具体使用

    1、应用中用到的一些配置信息放到ZK上进行集中管理

    这类场景通常是这样:应用在启动的时候会主动来获取一次配置,同时,在节点上注册一个Watcher,这样一来,以后每次配置有更新的时候,都会实时通知到订阅的客户端,从来达到获取最新配置信息的目的。

    2、分布式搜索服务

    分布式搜索服务中,索引的元信息和服务器集群机器的节点状态存放在ZK的一些指定节点,供各个客户端订阅使用。

    3、分布式日志收集系统

    这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用来分配收集任务单元,因此需要在ZK上创建一个以应用名作为path的节点P,并将这个应用的所有机器ip,以子节点的形式注册到节点P上,这样一来就能够实现机器变动的时候,能够实时通知到收集器调整任务分配。

    4、系统中有些信息需要动态获取

    系统中有些信息需要动态获取,并且还会存在人工手动去修改这个信息的发问。通常是暴露出接口,例如JMX接口,来获取一些运行时的信息。引入ZK之后,就不用自己实现一套方案了,只要将这些信息存放到指定的ZK节点上即可。

    注意:在上面提到的应用场景中,有个默认前提是:数据量很小,但是数据更新可能会比较快的场景。

    应用举例

    例如:同一个应用系统需要多台 PC Server 运行,但是它们运行的应用系统的某些配置项是相同的,如果要修改这些相同的配置项,那么就必须同时修改每台运行这个应用系统的 PC Server,这样非常麻烦而且容易出错。将配置信息保存在 Zookeeper 的某个目录节点中,然后将所有需要修改的应用机器监控配置信息的状态,一旦配置信息发生变化,每台应用机器就会收到 Zookeeper 的通知,然后从 Zookeeper 获取新的配置信息应用到系统中。ZooKeeper配置管理服务如下图所示:

    这里写图片描述
    配置管理结构图

    Zookeeper 很容易实现这种集中式的配置管理,比如将所需要的配置信息放到 /Configuration 节点上,集群中所有机器一启动就会通过Client对 /Configuration 这个节点进行监控【zk.exist("/Configuration″,true)】,并且实现 Watcher 回调方法process(),那么在 zookeeper 上 /Configuration 节点下数据发生变化的时候,每个机器都会收到通知,Watcher 回调方法将会被执行,那么应用再取下数据即可【zk.getData("/Configuration″,false,null)】。

    场景二:负载均衡


    典型场景描述(ZK特性,使用方法)

    这里说的负载均衡是指软负载均衡。在分布式环境中,为了保证高可用性,通常同一个应用或同一个服务的提供方都会部署多份,达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑,其中比较典型的是消息中间件中的生产者,消费者负载均衡

    具体使用

    消息中间件中发布者和订阅者的负载均衡。linkedin开源的 KafkaMQ 和阿里开源的 metaq 都是通过 zookeeper 来做到生产者、消费者的负载均衡。这里以 metaq 为例如讲下:

    生产者负载均衡

    metaq 发送消息的时候,生产者在发送消息的时候必须选择一台 broker上的一个分区来发送消息,因此 metaq 在运行过程中,会把所有 broker 和对应的分区信息全部注册到 ZK 指定节点上,默认的策略是一个依次轮询的过程,生产者在通过 ZK 获取分区列表之后,会按照 brokerIdpartition 的顺序排列组织成一个有序的分区列表,发送的时候按照从头到尾循环往复的方式选择一个分区来发送消息。

    消费负载均衡

    在消费过程中,一个消费者会消费一个或多个分区中的消息,但是一个分区只会由一个消费者来消费。MetaQ 的消费策略是:

    • 每个分区针对同一个 group 只挂载一个消费者;
    • 如果同一个 group 的消费者数目大于分区数目,则多出来的消费者将不参与消费;
    • 如果同一个 group 的消费者数目小于分区数目,则有部分消费者需要额外承担消费任务。

    在某个消费者故障或者重启等情况下,其他消费者会感知到这一变化(通过 zookeeper watch 消费者列表),然后重新进行负载均衡,保证所有的分区都有消费者进行消费。

    场景三:统一命名服务(Naming Service)


    典型场景描述(ZK特性,使用方法)

    分布式应用中,通常需要有一套完整的命名规则,既能够产生唯一的名称又便于人识别和记住,通常情况下用树形的名称结构是一个理想的选择,树形的名称结构是一个有层次的目录结构,既对人友好又不会重复。说到这里你可能想到了 JNDI,没错 Zookeeper 的 Name Service 与 JNDI 能够完成的功能是差不多的,它们都是将有层次的目录结构关联到一定资源上,但是 Zookeeper 的 Name Service 更加是广泛意义上的关联,也许你并不需要将名称关联到特定资源上,你可能只需要一个不会重复名称,就像数据库中产生一个唯一的数字主键一样。

    具体使用

    在分布式系统中,通过使用命名服务,客户端应用能够根据指定的名字来获取资源服务的地址提供者等信息。被命名的实体通常可以是集群中的机器,提供的服务地址进程对象等等,这些我们都可以统称他们为名字(Name)。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的API,能够很容易创建一个全局唯一的path,这个path就可以作为一个名称。Name Service 已经是Zookeeper 内置的功能,你只要调用 Zookeeper 的 API 就能实现。如调用 create 接口就可以很容易创建一个目录节点。

    应用举例

    阿里巴巴集团开源的分布式服务框架 Dubbo 中使用 ZooKeeper 来作为其命名服务,维护全局的服务地址列表,点击这里查看Dubbo开源项目。在Dubbo实现中:

      服务提供者在启动的时候,向 ZK 上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址,这个操作就完成了服务的发布。服务消费者启动的时候,订阅/dubbo/${serviceName}/providers目录下的提供者URL地址, 并向/dubbo/${serviceName} /consumers目录下写入自己的URL地址。

    注意,所有向 ZK 上注册的地址都是临时节点,这样就能够保证服务提供者和消费者能够自动感应资源的变化。

    另外,Dubbo还有针对服务粒度的监控,方法是订阅/dubbo/${serviceName}目录下所有提供者和消费者的信息。

    场景四:分布式通知/协调(Distribution of notification/coordination)


    典型场景描述(ZK特性,使用方法)

    ZooKeeper中特有watcher注册异步通知机制,能够很好的实现分布式环境下不同系统之间的通知与协调,实现对数据变更的实时处理。使用方法通常是不同系统都对 ZK 上同一个 znode 进行注册,监听 znode 的变化(包括 znode 本身内容及子节点的),其中一个系统 update 了 znode,那么另一个系统能够收到通知,并作出相应处理

    具体使用

    1、另一种心跳检测机制

    检测系统被检测系统之间并不直接关联起来,而是通过zk上某个节点关联,大大减少系统耦合。

    2、另一种系统调度模式

    某系统有控制台推送系统两部分组成,控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台作的一些操作,实际上是修改了ZK上某些节点的状态,而ZK就把这些变化通知给他们注册Watcher的客户端,即推送系统,于是,作出相应的推送任务。

    3、另一种工作汇报模式

    一些类似于任务分发系统,子任务启动后,到 zk 来注册一个临时节点,并且定时将自己的进度进行汇报(将进度写回这个临时节点),这样任务管理者就能够实时知道任务进度。

    总之,使用 zookeeper 来进行分布式通知和协调能够大大降低系统之间的耦合。

    场景五:集群管理与Master选举


    典型场景描述(ZK特性,使用方法)

    1、集群机器监控

    这通常用于那种对集群中机器状态,机器在线率有较高要求的场景,能够快速对集群中机器变化作出响应。这样的场景中,往往有一个监控系统,实时检测集群机器是否存活。过去的做法通常是:监控系统通过某种手段(比如ping)定时检测每个机器,或者每个机器自己定时向监控系统汇报“我还活着”。 这种做法可行,但是存在两个比较明显的问题:

    1. 集群中机器有变动的时候,牵连修改的东西比较多;
    2. 有一定的延时。

    利用ZooKeeper的两个特性,就可以实施另一种集群机器存活性监控系统:

    1. 客户端在节点 x 上注册一个Watcher,那么如果 x 的子节点变化了,会通知该客户端;
    2. 创建EPHEMERAL类型的节点,一旦客户端和服务器的会话结束或过期,那么该节点就会消失。

    例如,监控系统在 /clusterServers 节点上注册一个Watcher,以后每动态加机器,那么就往 /clusterServers 下创建一个 EPHEMERAL 类型的节点:/clusterServers/{hostname}。 这样,监控系统就能够实时知道机器的增减情况,至于后续处理就是监控系统的业务了。

    2、Master 选举则是 zookeeper 中最为经典的应用场景了

    在分布式环境中,相同的业务应用分布在不同的机器上,有些业务逻辑(例如一些耗时的计算,网络I/O处理),往往只需要让整个集群中的某一台机器进行执行,其余机器可以共享这个结果,这样可以大大减少重复劳动,提高性能,于是这个 master 选举便是这种场景下的碰到的主要问题。

    利用ZooKeeper中两个特性,就可以实施另一种集群中Master选举:

    • 利用ZooKeeper的强一致性,能够保证在分布式高并发情况下节点创建的全局唯一性,即:同时有多个客户端请求创建 /currentMaster 节点,最终一定只有一个客户端请求能够创建成功。利用这个特性,就能很轻易的在分布式环境中进行集群选取了。
    • 另外,这种场景演化一下,就是动态 Master 选举。这就要用到 EPHEMERAL_SEQUENTIAL 类型节点的特性了。

    上文中提到,所有客户端创建请求,最终只有一个能够创建成功。在这里稍微变化下,就是允许所有请求都能够创建成功,但是得有个创建顺序,于是所有的请求最终在 ZK 上创建结果的一种可能情况是这样:/currentMaster/{sessionId}-1 ,/currentMaster/{sessionId}-2 ,/currentMaster/{sessionId}-3 ….. 每次选取序列号最小的那个机器作为 Master,如果这个机器挂了,由于他创建的节点会马上消失,那么之后最小的那个机器就是 Master 了。

    应用举例

    1、集群监控

    应用集群中,我们常常需要让每一个机器知道集群中或依赖的其他某一个集群中哪些机器是活着的,并且在集群机器因为宕机,网络断链等原因能够不在人工介入的情况下迅速通知到每一个机器,Zookeeper 能够很容易的实现集群管理的功能,如有多台 Server 组成一个服务集群,那么必须要一个”总管”知道当前集群中每台机器的服务状态,一旦有机器不能提供服务,集群中其它集群必须知道,从而做出调整重新分配服务策略。同样当增加集群的服务能力时,就会增加一台或多台 Server,同样也必须让”总管”知道,这就是ZooKeeper的集群监控功能。

    这里写图片描述

    比如我在zookeeper服务器端有一个znode叫/Configuration,那么集群中每一个机器启动的时候都去这个节点下创建一个EPHEMERAL类型的节点,比如server1创建/Configuration /Server1,server2创建/Configuration /Server2,然后Server1和Server2都watch /Configuration 这个父节点,那么也就是这个父节点下数据或者子节点变化都会通知对该节点进行watch的客户端。因为EPHEMERAL类型节点有一个很重要的特性,就是客户端和服务器端连接断掉或者session过期就会使节点消失,那么在某一个机器挂掉或者断链的时候,其对应的节点就会消 失,然后集群中所有对/Configuration进行watch的客户端都会收到通知,然后取得最新列表即可。

    2、Master选举

    Zookeeper 不仅能够维护当前的集群中机器的服务状态,而且能够选出一个”总管”,让这个总管来管理集群,这就是 Zookeeper 的另一个功能 Leader Election。Zookeeper 如何实现 Leader Election,也就是选出一个 Master Server。和前面的一样每台 Server 创建一个 EPHEMERAL 目录节点,不同的是它还是一个 SEQUENTIAL 目录节点,所以它是个 EPHEMERAL_SEQUENTIAL 目录节点。之所以它是 EPHEMERAL_SEQUENTIAL 目录节点,是因为我们可以给每台 Server 编号,我们可以选择当前是最小编号的 Server 为 Master,假如这个最小编号的 Server 死去,由于是 EPHEMERAL 节点,死去的 Server 对应的节点也被删除,所以当前的节点列表中又出现一个最小编号的节点,我们就选择这个节点为当前 Master。这样就实现了动态选择 Master,避免了传统意义上单 Master 容易出现单点故障的问题。

    具体使用

    1、搜索系统

    在搜索系统中,如果集群中每个机器都生成一份全量索引,不仅耗时,而且不能保证彼此之间索引数据一致。因此让集群中的Master来进行全量索引的生成,然后同步到集群中其它机器。另外,Master选举的容灾措施是,可以随时进行手动指定master,就是说应用在zk无法获取master信息时,可以通过比如http方式,向一个地方获取master。

    2、Hbase

    Hbase中,也是使用ZooKeeper来实现动态HMaster的选举。在 Hbase 实现中,会在 ZK 上存储一些 ROOT 表的地址和 HMaster 的地址,HRegionServer 也会把自己以临时节点(Ephemeral)的方式注册到 Zookeeper 中,使得 HMaster 可以随时感知到各个 HRegionServer 的存活状态,同时,一旦 HMaster 出现问题,会重新选举出一个 HMaster 来运行,从而避免了 HMaster 的单点问题。

    场景六:分布式锁(Distribute Lock)


    典型场景描述(ZK特性,使用方法)

    分布式锁,这个主要得益于 ZooKeeper 为我们保证了数据的强一致性,即用户只要完全相信每时每刻,zk集群中任意节点(一个zk server)上的相同znode的数据是一定是相同的。锁服务可以分为两类,一个是保持独占,另一个是控制时序

    1、保持独占

    所谓保持独占,就是所有试图来获取这个锁的客户端,最终只有一个可以成功获得这把锁。通常的做法是把 zk 上的一个 znode 看作是一把锁,通过create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点,最终成功创建的那个客户端也即拥有了这把锁。

    2、控制时序

    控制时序,就是所有试图来获取这个锁的客户端,最终都是会被安排执行,只是有个全局时序了。做法和上面基本类似,只是这里 /distribute_lock 已经预先存在,客户端在它下面创建临时有序节点(这个可以通过节点的属性控制:CreateMode.EPHEMERAL_SEQUENTIAL来指定)。Zk 的父节点(/distribute_lock)维持一份sequence,保证子节点创建的时序性,从而也形成了每个客户端的全局时序。

    应用举例

    共享锁在同一个进程中很容易实现,但是在跨进程或者在不同 Server 之间就不好实现了。Zookeeper 却很容易实现这个功能,实现方式也是需要获得锁的 Server 创建一个 EPHEMERAL_SEQUENTIAL 目录节点,然后调用 getChildren 方法获取当前的目录节点列表中最小的目录节点是不是就是自己创建的目录节点,如果正是自己创建的,那么它就获得了这个锁,如果不是那么它就调用 exists(String path, boolean watch) 方法并监控 Zookeeper 上目录节点列表的变化,一直到自己创建的节点是列表中最小编号的目录节点,从而获得锁,释放锁很简单,只要删除前面它自己所创建的目录节点就行了。

    这里写图片描述

    场景七:分布式队列


    典型场景描述(ZK特性,使用方法)

    Zookeeper 可以处理两种类型的队列:

    • 当一个队列的成员都聚齐时,这个队列才可用,否则一直等待所有成员到达,这种是同步队列
    • 队列按照 FIFO 方式进行入队和出队操作,例如实现生产者和消费者模型。

    同步队列用 Zookeeper 实现的实现思路如下:

    创建一个父目录 /synchronizing,每个成员都监控(Set Watch)标志位目录 /synchronizing/start 是否存在,然后每个成员都加入这个队列,加入队列的方式就是创建 /synchronizing/member_i 的临时目录节点,然后每个成员获取 /synchronizing 目录的所有目录节点,也就是 member_i。判断 i 的值是否已经是成员的个数,如果小于成员个数等待 /synchronizing/start 的出现,如果已经相等就创建 /synchronizing/start。

    用下面的流程图更容易理解:

    这里写图片描述

    FIFO 队列用 Zookeeper 实现思路如下:

    实现的思路也非常简单,就是在特定的目录下创建 SEQUENTIAL 类型的子目录 /queue_i,这样就能保证所有成员加入队列时都是有编号的,出队列时通过 getChildren( ) 方法可以返回当前所有的队列中的元素,然后消费其中最小的一个,这样就能保证 FIFO。


    ZooKeeper 实际应用


    假设我们的集群有:

    1. 20个搜索引擎的服务器:每个负责总索引中的一部分的搜索任务。
      1. 搜索引擎的服务器中的15个服务器现在提供搜索服务。
      2. 5个服务器正在生成索引。
    2. 一个总服务器:负责向这20个搜索引擎的服务器发出搜索请求并合并结果集。
    3. 一个备用的总服务器:负责当总服务器宕机时替换总服务器。
    4. 一个web的cgi:向总服务器发出搜索请求。

    使用Zookeeper可以保证:

    1. 总服务器:自动感知有多少提供搜索引擎的服务器,并向这些服务器发出搜索请求。
    2. 备用的总服务器:宕机时自动启用备用的总服务器。
    3. web的cgi:能够自动地获知总服务器的网络地址变化。

    实现如下:

    1. 提供搜索引擎的服务器都在 Zookeeper 中创建 znode,zk.create("/search/nodes/node1", "hostname".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateFlags.EPHEMERAL);
    2. 总服务器可以从 Zookeeper 中获取一个 znode 的子节点的列表,zk.getChildren("/search/nodes", true);
    3. 总服务器遍历这些子节点,并获取子节点的数据生成提供搜索引擎的服务器列表;
    4. 当总服务器接收到子节点改变的事件信息,重新返回第二步;
    5. 总服务器在 Zookeeper 中创建节点,zk.create("/search/master", "hostname".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateFlags.EPHEMERAL);
    6. 备用的总服务器监控Zookeeper中的 “/search/master” 节点。当这个 znode 的节点数据改变时,把自己启动变成总服务器,并把自己的网络地址数据放进这个节点。
    7. web 的 cgi 从 Zookeeper 中”/search/master”节点获取总服务器的网络地址数据,并向其发送搜索请求。
    8. web 的 cgi 监控 Zookeeper 中的”/search/master”节点,当这个 znode 的节点数据改变时,从这个节点获取总服务器的网络地址数据,并改变当前的总服务器的网络地址。

    这20个搜索引擎的服务器,经常要让正在提供搜索服务的服务器停止提供服务开始生成索引,或生成索引的服务器已经把索引生成完成可以搜索提供服务了。

    展开全文
  • TimePatient 智能制造随笔 APS已经得到了大家的广泛重视和应用。APS的定义有很多。...但接触的企业多了,其实可以发现,Aps或者说类似APs的这种进行作业事项安排的应用场景还是很多的,当然了,不同的场景...

    TimePatient 智能制造随笔

    4220658e80759e78490c6c761b83e126.png

    APS已经得到了大家的广泛重视和应用。APS的定义有很多。但其实APS就是在计算:在什么时间在什么资源上面做什么事。从广义的角度来说,任何计划的制定其实都可以归入到APS的范畴里面。从狭义的角度来说,我们甚至都是在特指类似机加作业计划一样的安排。但接触的企业多了,其实可以发现,Aps或者说类似APs的这种进行作业事项安排的应用场景还是很多的,当然了,不同的场景及应用重点也是不一样的。

    (1)机加或离散加工为主

    这是一种最典型的生产应用场景,但其实这也是一种相对来说非常复杂的一种场景,APS就是从这个方面发展起来的,但是APS基本上也是陷入这个方面的“泥潭”。

    (2)以装配为主的

    这个主要就应该向供应链方面进行延伸,因为生产计划和这种供应计划是紧密衔接的。这种企业的APS,其实隐含了两层意思,一个是AP,一个是AS,甚至涉及到需求预测,也是我们通常说的MTO和MTS混合的一种模式。

    (3)加工和装配混合形式

    这个就要求加工计划和装备计划要进行衔接,尤其是自己的自制要和这个件生产完了之后为谁来使用的计划要进行衔接,这个也是企业里面非常常见的一种形式。

    (4)批量性生产方式

    其实对于大批量生产,如果将整个批次看成一体的话,这种APS排产其实是比较简单的,但这种APS排产的一个特点就是要和出产的计划要求相匹配,也会有相应的一些客户交货期,客户交货顺序等等的约束等。这种形式的APS很大程度上其实也含了一种优化分批的决策在里面。

    (5)物流调度

    对物流调度来说,其实我们可以从本质上的角度来看,也就是物流任务和物流资源的一种配置安排。企业常见的是两种形式,一种是以物流小车甚至物流车的这种调度计划配置。一种是自动化程度较高的托盘或者挂篮那种,简单的话算是一种执行,复杂的话涉及到软硬件一体化的集控,类似有点软件定义制造的味道。

    其实还是那句话,凡事涉及到,任务和资源匹配安排的这种场景,其实广义上来说,都可以说是一种APS

    展开全文
  • # 典型应用场景可以这样说,任何一个开发语言、开发框架,都有它存在的明确目的,重心为了解决什么问题。没有说我们学习一门语言或技术,就可以解决所有的问题。同样的,`OpenResty`的存在也有其自身适用的应用...

    # 典型应用场景

    可以这样说,任何一个开发语言、开发框架,都有它存在的明确目的,重心是为了解决什么问题。没有说我们学习一门语言或技术,就可以解决所有的问题。同样的,`OpenResty`的存在也有其自身适用的应用场景。

    其实官网 wiki 已经列了出来:

    - 在lua中混合处理不同nginx模块输出(proxy, drizzle, postgres, redis, memcached等)。

    - 在请求真正到达上游服务之前,lua中处理复杂的准入控制和安全检查。

    - 比较随意的控制应答头(通过Lua)。

    - 从外部存储中获取后端信息,并用这些信息来实时选择哪一个后端来完成业务访问。

    - 在内容handler中随意编写复杂的web应用,同步编写异步访问后端数据库和其他存储。

    - 在rewrite阶段,通过Lua完成非常复杂的处理。

    - 在Nginx子查询、location调用中,通过Lua实现高级缓存机制。

    - 对外暴露强劲的Lua语言,允许使用各种Nginx模块,自由拼合没有任何限制。该模块的脚本有充分的灵活性,同时提供的性能水平与本地C语言程序无论是在CPU时间方面以及内存占用差距非常小。所有这些都要求LuaJIT 2.x是启用的。其他脚本语言实现通常很难满足这一性能水平。

    #### 不擅长的应用场景

    前面的章节,我们是从它适合的场景出发,`OpenResty`不适合的场景又有哪些?以及我们在使用中如何规避这些问题呢?

    这里官网并没有给出答案,我根据我们的应用场景给大家列举,并简单描述一下原因:

    - 有长时间阻塞调用的过程

    - 例如通过 `Lua` 完成系统命令行调用

    - 使用阻塞的`Lua API`完成相应操作

    - 单个会话处理逻辑复杂,尤其是需要和请求方多次交互的长连接场景

    - `Nginx`的内存池 pool 是每次新申请内存存放数据

    - 所有的内存释放都是在会话退出的时候统一释放

    - 如果单个会话处理过于复杂,将会有过多内存无法及时释放

    - 内存占用高的处理

    - 受制于`Lua VM`的最大使用内存 1G 的限制

    - 这个限制是单个`Lua VM`,也就是单个`Nginx worker`

    - 两个会话之间有交流的场景

    - 例如你做个在线聊天,要完成两个用户之间信息的传递

    - 当前`OpenResty`还不具备这个通讯能力(后面可能会有所完善)

    - 与行业专用的组件对接

    - 最好是 TCP 协议对接,不要是 API 方式对接,防止里面有阻塞 TCP 处理

    - 由于`OpenResty`必须要使用非阻塞 API ,所以传统的阻塞 API ,我们是没法直接使用的

    - 获取 TCP 协议,使用 cosocket 重写(重写后的效率还是很赞的)

    - 每请求开启的 `light thread` 过多的场景

    - 虽然已经是`light thread`,但它对系统资源的占用相对是比较大的

    这些适合、不适合信息可能在后面随着 `OpenResty` 的发展都会有新的变化,大家拭目以待。

    展开全文
  • 因此为大家整理一些阿里云典型应用场景,以及每一种应用场景主要涉及的技术,给大家提供一个参考。相信看完本文,大家都能清楚的知道自己要实现的应用大概会需要用到什么样的服务和产品。 一、一站式建站 阿里云...

    阿里云的产品可谓是多种多样,纷繁复杂。面对各种各样的技术和产品,ECS、RDS、OSS…等等一系列的东西,很容易让人找不到头绪,尤其是刚刚开始接触网站建设的朋友。因此为大家整理一些阿里云典型的应用场景,以及每一种应用场景主要涉及的技术,给大家提供一个参考。相信看完本文,大家都能清楚的知道自己要实现的应用大概会需要用到什么样的服务和产品。

    一、一站式建站
    阿里云提供域名和云解析服务,云市场还提供全程建站服务。小型网站只需一台云服务器ECS即可。

    1、域名注册:国内域名市场NO.1,19年专业域名服务,超30种域名供您选择;2、云解析:提供安全、稳定、极速的域名解析服务,每天超百亿次解析响应;3、免费备案:人脸识别,备多久云服务器免费送多久;4、建站服务:服务全程监管,不满意全额退款;5、云服务器:可弹性伸缩、安全稳定、简单易用。

    更多云服务器内容介绍请参考:阿里云帮助中心-云服务器ECS知识库

    二、随时灵活扩展
    建议使用过弹性伸缩结合云服务器,实现在业务增长/下降时自动增加/减少云服务器实例。

    1、网站初始阶段访问量小,应用程序、数据库、文件等所有资源均在一台云服务器上,节省初创成本;2、用户使用镜像可免安装快速部署,提供php、Java、asp、asp.net等运行环境;3、当您开始营销推广,网站流量可能会出现成倍的增幅,使用台云服务器可以在几分钟内完成扩容,轻松应对,搭配负载均衡,实现水平扩容;4、如果你的业务存在明显的波峰/谷,或无法预估流量波动,建议使用过弹性伸缩,实现在业务增长/下降时自动增加/减少云服务器实例。

    三、加快访问速度
    OSS与CDN搭配,解决网站海量图。OSS与CDN搭配,解决网站海量图片存储问题片存储问题

    1、不同地区的用户访问网站出现延时问题时,可使用CDN加速,CDN在国内有500+节点,海外有30+节点,覆盖教育网、电信、移动、铁通、联通、鹏博士等运营商;2、如果您的网站有大量静态资源,建议将站点内容进行动静分离,使用CDN结合OSS存储海量静态资源,有效加速内容加载速度,轻松搞定网站图片、短视频等内容分发;3、如果您的网站业务包括视音频点播、大文件下载如安装包下载、,建议使用CDN搭配OSS,提升回源速度,节约近2/3回源带宽成本。

    四、海量图片存储
    OSS与CDN搭配,解决网站海量图。OSS与CDN搭配,解决网站海量图片存储问题片存储问题

    1、使用云服务器存储大量图片存储及带宽成本较高,您可以使用CDN,CDN搭配OSS支持直接写入或读取数据,包括流式写入和文件写入两种方式;2、如果您的网站有大量静态资源,建议将站点内容进行动静分离,使用CDN结合OSS存储海量静态资源,有效加速内容加载速度,轻松搞定网站图片、短视频等内容分发;3、如果您需要对海量图片加速分发,建议使用CDN搭配OSS,大幅加速分发,降低成本。

    五、应对高并发
    阿里云提供负载均衡搭配云服务器,应对任意并发压力,也可以通过开放缓存服务对热点数据进行缓存,在数据层可用DRDS实现分库分表。

    1、在Web层,自己搭建并维护负载均衡系统成本较高。阿里云提供的负载均衡搭配云服务器,实现水平扩容,理论上可应对任意并发压力,较传统技术更简单易用;2、在静态资源方面:高并发带来的访问性能等问题,可以通过CDN加速静态文件访问解决;3、在缓存层:大部分网站访问都遵循28原则,即80%的访问请求,最终落在20%的数据上。因此,可以使用OCS对热点数据进行缓存,减少这些数据的访问路径和数据库的压力;4、在数据层:用RDS实现读写分离、用DRDS实现分库分表,可以轻松解决高并发带来的容量和性能问题。

    六、网站防攻击
    云盾基础防护免费提供最高5G的默认DDoS防护能力和应用防护能力,针对暴力破解行为可用安骑士,针对大流量DDOS攻击可用高防IP。

    1、网站是最容易遭受攻击的应用类型,黑客通过真实服务器发起DDoS攻击或者CC攻击很容易就能使网站陷入瘫痪,云盾基础防护免费提供最高5G的默认DDoS防护能力和应用防护能力;2、遭受大流量的DDoS攻击后,用户可以通过配置高防IP,将攻击流量引流到高防IP,确保源站的稳定可靠;3、针对暴力破解等行为,安骑士可在云端处理中心实时对所有插件的数据进行汇总和分析,若匹配到暴力破解行为则会立即对该IP进行拦截,保障服务器不被黑客暴力猜解密码。

    七、数据备份
    云服务器支持创建快照来做数据备份,OSS提供静态文件的三重备份,阿里云的云数据库RDS提供自动和手动两种备份方式,每天自动备份数据并上传至对象存储OSS。

    1、服务器数据备份:云服务器支持手动或自动创建实例的快照,保留某个时间点上的系统数据状态,作为数据备份,或者制作镜像,每个磁盘拥有64个快照quota;2、静态数据文件备份:OSS提供三重备份,故障自动恢复能力,保障数据可靠性99.99999999%;3、数据库备份:阿里云的云数据库RDS提供自动和手动两种备份方式,每天自动备份数据并上传至对象存储OSS,提高数据容灾能力的同时有效降低磁盘空间占用。

    八、搜索/推荐
    开放搜索服务将专业搜索技术简单化、低门槛化和低成本化,也可以使用推荐引擎结合MaxCompute

    1、自己搭建、优化搜索引擎应用需要较高的技术成本,开放搜索服务将专业搜索技术简单化、低门槛化和低成本化;2、如果需要搭建自己的个性化推荐系统、实现『千人千面』的精准营销,可以使用推荐引擎结合MaxCompute,实时预测用户对物品偏好的数据工具,且企业定制个性化推荐算法,助力企业实现商业目标。

    九、网站迁移
    您可采用数据迁移服务,将本地数据库迁移到阿里云上,也可用ossimport2将本地静态文件同步到对象存储OSS中,您也可以直接使用云市场的网站迁移服务。

    1、备案转入:如果您想将已备案的网站迁入阿里云,仅需6步,就可免费实现,备多久云服务器免费送多久;2、数据库迁移:如果要将本地数据库迁移到阿里云上,可以使用DTS的增量迁移功能,不影响本地业务继续提供服务,从而最大程度降低数据迁移期间应用停服时间;3、静态文件迁移:ossimport2可以将您本地或第三方云存储服务上的文件同步到对象存储OSS上,支持多种文件迁移方式;4、云市场提供的网站迁移服务,可以帮助您省心省力实现迁移。


    十、可视化分析
    MaxCompute可以与ECS,ADS/RDS以及其他BI报表工具等配合使用,完成用户BI分析的需求

    1、个性化广告推广可以大幅提高推广销量,MaxCompute可以完成更为复杂的机器学习、数据挖掘等分析。帮助用户实现个性化推荐等广告推广场景,此外还可以完成BI报表等需求;2、数据可视化DataV、可以帮助非专业的工程师通过图形化的界面轻松搭建专业水准的可视化应用,满足日常业务监控、调度、会展演示等多场景使用需求。

    十一、服务全球客户

    建议阿里云服务器ECS的海外节点部署业务,不同地区的用户访问网站出现延时问题时,可使用CDN加速,CDN在国内有500+节点,海外有30+节点。

    1、您的客户可能位于世界上任何地方,使用阿里云可以在每一个地理区域拥有一处托管您网站的数据中心,包括美西、中东、亚太,而这一切只需点点鼠标就能完成。2、不同地区的用户访问网站出现延时问题时,可使用CDN加速,CDN在国内有500+节点,海外有30+节点,覆盖教育网、电信、移动、铁通、联通、鹏博士等运营商;3、如果您的网站有大量静态资源,建议将站点内容进行动静分离,使用CDN结合OSS存储海量静态资源,有效加速内容加载速度,轻松搞定网站图片、短视频等内容分发;4、如果您的网站业务包括视音频点播、大文件下载如安装包下载、,建议使用CDN搭配OSS,提升回源速度,节约近2/3回源带宽成本。

    十二、网站搭建
    您可将业务部署在阿里云服务器上,建站过程中阿里云也提供模板建站,定制建站等专业服务,最快三分钟即可建站。同时您也可联系阿里云专业建站团队,定制个性化网站。

    1、百款优质精美网站模板,含网站空间及流量,企业官网3分钟急速拥有2、电子商务,选择专业建站团队,快速搭建个性化网站3、离你最近的企业网站服务,按区域就近选择,服务更贴心4、高端定制网站,专属设计师团队,彰显品牌形象5、移动网站建设,定制手机官网,布局移动互联网。

    面对国内众多的云平台,个人和企业该如何选择呢?可以参考这篇文档:【云服务器推荐】2021年腾讯云、阿里云、华为云服务器价格和配置评测

    展开全文
  • 文章目录一、事件驱动型应用什么是事件驱动型应用?事件驱动型应用的优势?Flink 如何支持事件驱动型应用?二、事件分析型应用什么是数据分析应用?流式分析应用的优势?Flink 如何支持数据分析类应用?三、数据管道...
  • 一、ZooKeeper是什么?ZooKeeper是源代码开放的分布式协调服务,由雅虎创建,是Google Chubby的开源实现。ZooKeeper是一个高性能的分布式数据一致性解决方案,它将那些复杂的、容易出错的分布式一致性服务封装起来,...
  • 大数据典型应用场景

    万次阅读 2019-07-31 19:02:43
    今天我们通过一些大数据典型应用场景分析,一起来看看大数据到底能做些什么,我们学大数据究竟有什么用。医疗健康。比如,我们可以结合机器学习做到医学影像智能识别。图像识别机...
  • 本文讲的【实战】Docker的典型应用场景,【编者的话】Docker技术已日趋成熟,但很多新接触Docker的朋友可能对「Docker到底能用来干什么」这一问题比较纠结。本文总结了一些作者在应用打包、多版本混合部署、升级...
  • 1什么是配置维护 分布式系统中,很多服务都部署在集群中的,即多台服务器中部署着完全相同的应用,起着完全相同的作用。当然,集群中的这些服务器的配置文件完全相同。 若集群中服务器的配置文件需要进行修改...
  • ... 2)什么是发现?怎么发现? 3)什么是选举?为什么选举?...4)临时节点的生命周期是什么? 5)心跳的作用是什么? 可以参考https://www.cnblogs.com/sky-sql/p/6804467.html没有讲心跳检测 ...
  • 1什么是Master选举 集群分布式系统中不可或缺的组成部分,为了解决分布式系统中计算单元的单点问题,水平扩展计算单元的处理能力的一种解决方案。 一般情况下,会在群集中选举出一个Master,用于协调集群中的...
  • 物化视图oracle一个比较有特色的东西,自oracle9i起,应用非常广泛,不像mysql,不支持原生物化视图,要借助flexviews去实现。物化视图到底有什么用呢?要回答这个问题,必须先搞清楚物化视图与普通视图的区别: ...
  • 静态脱敏产品三个典型应用场景分析 在数据流动、共享、交换成为趋势的今天,数据脱敏已经成为实现敏感数据保护的重要手段之一。数据脱敏产品也逐步被金融、政府、企业等行业客户广泛使用。 当前数据脱敏产品主要...
  • 一、什么是命名服务? 命名服务(Naming Service),分布式系统中比较常见的一类场景。在分布式系统中,通过使用命名服务,客户端应用能够根据指定名字来获取资源戒服务的地址,提供者等信息。被命名的实体通常...
  • 什么是Barrier Barrier这样的:Barrier一个同步点,每一个进程到达此点都要等待,直到某一个条件满足,然后所有的节点继续进行。 比如:赛跑大家都知道,所有比赛人员都会在起跑线外等待,直到教练员的枪响之后,...
  • 【zookeeper系列】ZK典型应用场景

    万次阅读 2016-06-02 15:16:50
    Zookeeper 简称ZK,初次接触Zookeeper,大家首先想到的就是Zookeeper的应用场景,主要用来解决什么问题,归纳起来主要以下五方面的内容。 一、统一命名服务(Name Service)分布式应用中,通常需要有一套完整的...
  • 物化视图oracle一个比较有特色的东西,自oracle9i起,应用非常广泛,不像mysql,不支持原生物化视图,要借助flexviews去实现。物化视图到底有什么用呢?要回答这个问题,必须先搞清楚物化视图与普通视图的区别:...
  • ZooKeeper八大典型应用场景

    千次阅读 2020-01-26 17:18:57
    什么是配置中心,有什么用? 数据发布/订阅( Publish/Subscribe)系统,即所谓的配置中心,顾名思义就是发布者将数据发布到ZooKeeper的一个或一系列节点上,供订阅者进行数据订阅,进而达到动态获取数据的目的,实现...
  • 本文内容参考网络,侵删 本系列文章将整理到我在GitHub上的《Java面试指南》仓库,更多精彩内容请到我的仓库里...该系列博文会告诉你什么是分布式系统,这对后端工程师来说很重要的一门学问,我们会逐步了解常见...
  • 物化视图oracle一个比较有特色的东西,自oracle9i起,应用非常广泛,不像mysql,不支持原生物化视图,要借助flexviews去实现。物化视图到底有什么用呢?要回答这个问题,必须先搞清楚物化视图与普通视图的区别:...
  • 当前图中,这片连续的存储区可以数组,也可以链表(为什么连续的存储区也可以链表,后面 LeetCode题可以看到) 队列连续的存储区,可以存储一系列的元素。FIFO(先入先出,First-In-First-Out)结构。 ...
  • 原文地址,转载请注明出处:&...什么是Barrier Barrier这样的:Barrier一个同步点,每一个进程到达此点都要等待,直到某一个条件满足,然后所有的节点继续进行。 比如:赛跑大家都知道,所有...
  • Which One to Choose for Your Problem》,简明扼要地介绍了一些比较流行的机器学习算法的典型应用场景,下面摘录其中部分内容(由原作者授权论智翻译):线性回归和线性分类器这些可能机器学习中最简单的算法。...
  • 1.2 栈适合解决什么问题?栈思维,很重要 判断括号是否合法: 一种括号情况: 第一个条件解释: 一个变量就可以了,记录左右括号的差值即可 引出思维方式: [外链图片转存失败,源站可能有防盗链机制,建议将图片...
  • SYN5214型便携式频谱分析仪一款手持式频谱分析仪,测量范围为30MHz~6GHz,采用5英寸液晶屏设计,可覆盖当前流行的各种无线频段,包括WiFi、蓝牙、无线音视频、LORA、ZIGBEE、NB-lot等等,具有实时频谱图、频率...
  • php性状的应用场景 ,有一定的参考价值,有需要的朋友可以参考一下,希望对你有所帮助。为什么使用性状?PHP语言使用种典型的继承模型。 在这种模型中,我们先编写一个通用的根类,实现基本的功能,然后护展这个根类...
  • ZooKeeper 八种典型应用场景详细介绍 为进一步加强对 zk 的认识,理解 zk 的作用,下面再详细介绍一下 zk 在生产环境中的典型应用场景。 1. 配置维护 1.1 什么是配置维护 分布式系统中,很多服务都部署在集群中的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 922
精华内容 368
关键字:

典型应用场景是什么