CN107370797A - 一种基于HBase的强有序队列操作的方法和装置 - Google Patents

一种基于HBase的强有序队列操作的方法和装置 Download PDF

Info

Publication number
CN107370797A
CN107370797A CN201710526912.6A CN201710526912A CN107370797A CN 107370797 A CN107370797 A CN 107370797A CN 201710526912 A CN201710526912 A CN 201710526912A CN 107370797 A CN107370797 A CN 107370797A
Authority
CN
China
Prior art keywords
queue
message
hbase
request
queue operation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201710526912.6A
Other languages
English (en)
Other versions
CN107370797B (zh
Inventor
李雨明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Baidu Netcom Science and Technology Co Ltd
Original Assignee
Beijing Baidu Netcom Science and Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Baidu Netcom Science and Technology Co Ltd filed Critical Beijing Baidu Netcom Science and Technology Co Ltd
Priority to CN201710526912.6A priority Critical patent/CN107370797B/zh
Publication of CN107370797A publication Critical patent/CN107370797A/zh
Application granted granted Critical
Publication of CN107370797B publication Critical patent/CN107370797B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/548—Queue

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明提供了一种基于HBase的强有序队列操作的方法和装置，获取多个客户端发送的队列操作请求，其中，所述队列操作请求所针对的队列位于HBase分布式数据库中，若多个队列操作请求同时且针对同一队列，对所述多个队列操作请求进行竞争队列锁，对于锁成功的队列操作请求，对所述队列进行与所述队列操作请求相对应的队列操作，所述队列操作完成后，解除所述队列锁，重复执行上述步骤，直至完成对所述多个队列操作请求的执行，以实现基于HBase的强有序队列操作。与现有技术相比，本发明具有高性能强有序、高可用性、支持海量设备和数据不容易丢失等优点，可应用于云的物联网接入服务，性能好、可靠性高、水平扩展性强，满足海量用户和设备的接入。

Description

一种基于HBase的强有序队列操作的方法和装置
技术领域
本发明涉及计算机技术领域，尤其涉及一种基于HBase的强有序队列操作的技术。
背景技术
公有云上，物联网服务往往是多租户的，每个用户有不同的设备，每个订阅设备有自己的消息队列。随着用户数和设备数目的增多，队列数目和队列数据大小也会剧增，往往会成为性能上的瓶颈。
现有可用的分布式队列方案大都是用Redis或者Kafka来实现，首先从分布式角度，两者都支持集群模式，能够形成分布式系统。其次从队列角度，Redis支持队列结构，Kafka的topic满足消息的有序写入，都可以当成队列使用。最后在多租户角度，可以做逻辑上的划分，比如以user+client形成唯一ID，作为Redis的Key或者Kafka的topic，即可形成多租户的分布式队列系统。
然而，Redis和Kafka在一定程度上，可以满足小规模的需求，但无法满足规模更大，可靠性更高的场景。首先从Redis来说，它是基于内存的数据库，对于海量存储来说，成本会相当高，它的集群模式是主从式的，存在丢失数据的风险，比如在主从复制时主节点宕机，或者主从节点都宕机了，数据会出现不一致和丢失的情况。其次从Kafka来说，存在性能瓶颈问题，由于Kafka将topic等信息存储在zookeeper中，当topic数目达到一定规模后，即znode数目很多，zookeeper的限制会导致kafka性能急剧下降。可见，目前公有云物联网服务商无法支撑海量接入规模，也无法做到高可用性和高可靠性。
因此，如何提供一种能够支持海量用户和设备接入的方法，成为本领域技术人员亟需解决的技术问题一致。
发明内容
本发明的目的是提供一种基于HBase的强有序队列操作的方法和装置。
根据本发明的一个方面，提供了一种基于HBase的强有序队列操作的方法，其中，该方法包括：
a获取多个客户端发送的队列操作请求，其中，所述队列操作请求所针对的队列位于HBase分布式数据库中；
b若多个队列操作请求同时且针对同一队列，对所述多个队列操作请求进行竞争队列锁；
c对于锁成功的队列操作请求，对所述队列进行与所述队列操作请求相对应的队列操作；
d所述队列操作完成后，解除所述队列锁；
e重复执行步骤b至d，直至完成对所述多个队列操作请求的执行，以实现基于HBase的强有序队列操作。
优选地，所述队列操作包括以下至少任一项：
-消息队列创建；
-批量消息写入；
-批量消息删除；
-消息队列删除。
更优选地，所述队列操作包括批量消息写入，其中，该方法还包括：
基于所述队列操作请求，为所述队列的每个消息分配一个单调递增的消息ID，再结合用户ID和用户设备ID，确定每个消息所对应的行键。
更优选地，该方法还包括：
缓存所述队列的最小消息ID和最大消息ID，当所述队列操作包括批量消息写入时，所述最大消息ID进行递增，当所述队列操作包括批量消息删除时，所述最小消息ID递增。
更优选地，该方法还包括：
若所述缓存失效，利用HBase的扫描操作，读取所述队列中最小行键的一行和最大行键的一行，其中，所述行键中的消息ID对应所述队列的最小消息ID和最大消息ID。
优选地，该方法还包括：
根据所述行键的前两个字节，分裂HBase的区域。
优选地，该方法还包括：
所述客户端对来自各个对应用户设备的数据进行缓存，定时和/或定量地根据缓存后的数据，生成所述队列操作请求。
优选地，该方法还包括：
若HBase的其中一个区域出现异常，通过操作日志恢复消息数据，进行HLOG重塑。
根据本发明的另一个方面，还提供了一种基于HBase的强有序队列操作的有序装置，其中，该有序装置包括：
获取装置，用于获取多个客户端发送的队列操作请求，其中，所述队列操作请求所针对的队列位于HBase分布式数据库中；
竞争装置，用于若多个队列操作请求同时且针对同一队列，对所述多个队列操作请求进行竞争队列锁；
操作装置，用于对于锁成功的队列操作请求，对所述队列进行与所述队列操作请求相对应的队列操作；
解除装置，用于所述队列操作完成后，解除所述队列锁；
调度装置，用于调度所述竞争装置、操作装置和解除装置重复执行其操作，直至完成对所述多个队列操作请求的执行，以实现基于HBase的强有序队列操作。
优选地，所述队列操作包括以下至少任一项：
-消息队列创建；
-批量消息写入；
-批量消息删除；
-消息队列删除。
更优选地，所述队列操作包括批量消息写入，其中，该有序装置还包括：
确定装置，用于基于所述队列操作请求，为所述队列的每个消息分配一个单调递增的消息ID，再结合用户ID和用户设备ID，确定每个消息所对应的行键。
更优选地，该有序装置还包括：
缓存装置，用于缓存所述队列的最小消息ID和最大消息ID，当所述队列操作包括批量消息写入时，所述最大消息ID进行递增，当所述队列操作包括批量消息删除时，所述最小消息ID递增。
更优选地，该有序装置还包括：
读取装置，用于若所述缓存失效，利用HBase的扫描操作，读取所述队列中最小行键的一行和最大行键的一行，其中，所述行键中的消息ID对应所述队列的最小消息ID和最大消息ID。
优选地，该有序装置还包括：
分裂装置，用于根据所述行键的前两个字节，分裂HBase的区域。
优选地，所述客户端对来自各个对应用户设备的数据进行缓存，定时和/或定量地根据缓存后的数据，生成所述队列操作请求。
优选地，该有序装置还包括：
重塑装置，用于若HBase的其中一个区域出现异常，通过操作日志恢复消息数据，进行HLOG重塑。
根据本发明的又一个方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机代码，当所述计算机代码被执行时，如上任一项所述的方法被执行。
根据本发明的再一个方面，还提供了一种计算机程序产品，当所述计算机程序产品被计算机设备执行时，如上任一项所述的方法被执行。
根据本发明的再一个方面，还提供了一种计算机设备，所述计算机设备包括：
一个或多个处理器；
存储器，用于存储一个或多个计算机程序；
当所述一个或多个计算机程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上任一项所述的方法。
与现有技术相比，本发明具有以下优点：
高性能强有序：系统支持批量操作，大幅度提高读写性能，并且满足批量写入和读取的数据是一致有序的；
高可用性：系统可用性等同于HBase集群高可用性，可达99.999％；
支持海量设备：集群规模可水平扩展至几千台，性能几乎是线性提高的，所以理论上可满足百亿级设备接入；
数据不容易丢失：HBase底层采用HDFS存储，数据3备份，几乎不存在丢失可能。
进一步地，本发明提供的基于HBase实现的多租户强有序分布式消息系统，可以应用于云的物联网接入服务，性能好、可靠性高、水平扩展性强，满足海量用户和设备的接入。
进一步地，HBase中RegionServer的协处理器为每条消息确定一个优化的RowKey，更进一步地有利于对消息队列的强有序队列操作。
进一步地，通过对队列的最小消息ID和最大消息ID的缓存，或者通过HBase的scan操作以获得当前队列的最小消息ID和最大消息ID，保证对单次批量操作而言，批量写入/删除的消息是强有序的。因此，本发明的强有序可以包括两个方面，一是对单次批量操作而言，批量写入/删除的消息是有顺序性保证的；二是对竞争批量操作而言，用队列锁保证竞争情况下的有序性。
在此，本发明通过对HBase服务端的改造，解决了现有技术中单纯依靠客户端本身的改造所不能解决的问题。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：
图1示出根据本发明一个方面的一种基于HBase的强有序队列操作的有序装置的装置示意图；
图2示出根据本发明一个优选实施例的一种基于HBase的强有序队列操作的示意图；
图3示出根据本发明另一个优选实施例的一种基于HBase的强有序队列操作的示意图；
图4示出根据本发明又一个优选实施例的一种基于HBase的强有序队列操作的示意图；
图5示出根据本发明另一个方面的一种基于HBase的强有序队列操作的方法的流程示意图。
附图中相同或相似的附图标记代表相同或相似的部件。
具体实施方式
在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。
在上下文中所称“计算机设备”，也称为“电脑”，是指可以通过运行预定程序或指令来执行数值计算和/或逻辑计算等预定处理过程的智能电子设备，其可以包括处理器与存储器，由处理器执行在存储器中预存的存续指令来执行预定处理过程，或是由ASIC、FPGA、DSP等硬件执行预定处理过程，或是由上述二者组合来实现。计算机设备包括但不限于服务器、个人电脑、笔记本电脑、平板电脑、智能手机等。
所述计算机设备包括用户设备与网络设备。其中，所述用户设备包括但不限于电脑、智能手机、PDA等；所述网络设备包括但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(Cloud Computing)的由大量计算机或网络服务器构成的云，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。其中，所述计算机设备可单独运行来实现本发明，也可接入网络并通过与网络中的其他计算机设备的交互操作来实现本发明。其中，所述计算机设备所处的网络包括但不限于互联网、广域网、城域网、局域网、VPN网络等。
需要说明的是，所述用户设备、网络设备和网络等仅为举例，其他现有的或今后可能出现的计算机设备或网络如可适用于本发明，也应包含在本发明保护范围以内，并以引用方式包含于此。
后面所讨论的方法(其中一些通过流程图示出)可以通过硬件、软件、固件、中间件、微代码、硬件描述语言或者其任意组合来实施。当用软件、固件、中间件或微代码来实施时，用以实施必要任务的程序代码或代码段可以被存储在机器或计算机可读介质(比如存储介质)中。(一个或多个)处理器可以实施必要的任务。
这里所公开的具体结构和功能细节仅仅是代表性的，并且是用于描述本发明的示例性实施例的目的。但是本发明可以通过许多替换形式来具体实现，并且不应当被解释成仅仅受限于这里所阐述的实施例。
应当理解的是，虽然在这里可能使用了术语“第一”、“第二”等等来描述各个单元，但是这些单元不应当受这些术语限制。使用这些术语仅仅是为了将一个单元与另一个单元进行区分。举例来说，在不背离示例性实施例的范围的情况下，第一单元可以被称为第二单元，并且类似地第二单元可以被称为第一单元。这里所使用的术语“和/或”包括其中一个或更多所列出的相关联项目的任意和所有组合。
应当理解的是，当一个单元被称为“连接”或“耦合”到另一单元时，其可以直接连接或耦合到所述另一单元，或者可以存在中间单元。与此相对，当一个单元被称为“直接连接”或“直接耦合”到另一单元时，则不存在中间单元。应当按照类似的方式来解释被用于描述单元之间的关系的其他词语(例如“处于...之间”相比于“直接处于...之间”，“与...邻近”相比于“与...直接邻近”等等)。
这里所使用的术语仅仅是为了描述具体实施例而不意图限制示例性实施例。除非上下文明确地另有所指，否则这里所使用的单数形式“一个”、“一项”还意图包括复数。还应当理解的是，这里所使用的术语“包括”和/或“包含”规定所陈述的特征、整数、步骤、操作、单元和/或组件的存在，而不排除存在或添加一个或更多其他特征、整数、步骤、操作、单元、组件和/或其组合。
还应当提到的是，在一些替换实现方式中，所提到的功能/动作可以按照不同于附图中标示的顺序发生。举例来说，取决于所涉及的功能/动作，相继示出的两幅图实际上可以基本上同时执行或者有时可以按照相反的顺序来执行。
下面结合附图对本发明作进一步详细描述。
图1示出根据本发明一个方面的一种基于HBase的强有序队列操作的有序装置的装置示意图。
该有序装置1包括获取装置101、竞争装置102、操作装置103、解除装置104和调度装置105。
其中，获取装置101获取多个客户端发送的队列操作请求，其中，所述队列操作请求所针对的队列位于HBase分布式数据库中。
具体地，客户端可以向有序装置1发送队列操作请求，如RPC请求，该客户端例如可以是Broker，或进一步包括位于该Broker中的HBase-Client组件。该有序装置1例如位于HBase-Server，或进一步地，Region Server中，通过对HBase服务端的改造，解决了现有技术中单纯依靠客户端本身的改造所不能解决的问题。在此，Broker是一个设备接入端，其可以分别接入不同用户的不同用户设备，其可以被看成消息转发器，同时也负责一些控制和管理操作。该Broker例如通过其上的HBase-Client，向对应的HBase-Server发送队列操作请求，获取装置101通过与该客户端进行交互，例如，通过一次或多次调用客户端的应用程序接口(API)或通过其他约定的通信方式，获取该客户端发送的队列操作请求。进一步地，获取装置101可以获取多个客户端所发送的队列操作请求。该队列操作请求所针对的队列位于HBase分布式数据库中。
在此，基于HBase来设计实现多租户强有序的分布式队列系统，采用了HBase作为底层系统，其可以利用HBase的region(区域)分裂特性，不同region会位于不同的RegionServer上，Region Server可以通过添加机器的方式水平扩展。在此，该region是HBase中存储和管理的基本单元。
优选地，HBase-Client可以通过来自对应Broker的队列操作请求中的信息进行寻址，寻址定位到该队列操作请求的目标消息队列是在HBase的哪个region，然后将该队列操作请求发送至该region所在的Region Server上，Region Server上的有序装置1的获取装置101获取该队列操作请求。
本领域技术人员应能理解，上述获取队列操作请求的方式仅为举例，其他现有或今后可能出现的获取队列操作请求的方式，如可适用于本发明，也应包含在本发明保护范围以内，并在此以引用的方式包含于此。
若多个队列操作请求同时且针对同一队列，竞争装置102对所述多个队列操作请求进行竞争队列锁。
具体地，由于对于同一个队列，同一时间可能有多个队列操作请求，如消息队列创建请求、批量消息写入请求、批量消息删除请求或消息队列删除请求等，为了保证一个队列操作里的消息的有序性，对于每个队列操作请求，都可以先去获取队列锁，竞争装置102可以通知该多个队列操作请求去竞争队列锁，例如，对于HBase-Client所发送的RPC请求，HBase-Server都会为每个请求分配一个线程来进行处理，多个线程去竞争该队列锁，看谁先获取到该队列锁。该队列锁是一个公平锁，具有加锁和未加锁两种状态，当其中一个线程获取到该队列锁，即锁成功，则该队列锁即是加锁状态；当该线程处理完对该队列的操作，即可以释放该队列锁，则该队列锁又变成未加锁状态。对于获取队列锁失败的队列操作请求会阻塞，当前一个操作释放锁后，请求继续进行，然后返回。因此，当请求竞争出现时，通过队列锁可以保证请求是顺序执行的。
操作装置103对于锁成功的队列操作请求，对所述队列进行与所述队列操作请求相对应的队列操作。
在此，由于HBase原生操作只支持写入PUT、读取GET、删除DELETE和扫描读Scan，无法满足队列的基本操作，因此，可以自定义针对队列的操作，操作原语是通过protobuf定义的RPC请求和响应，操作执行将由客户端发起请求，服务端处理请求后给出响应。首先定义Reverse(UniqueClinetID)+UserID为队列名称queueName，该队列名称的定义将在下文进行详细描述。该队列名称可唯一标识一个队列，对于该队列定义了如下操作：
消息队列创建请求：给定队列名称及队列最大长度限制，创建一个队列；
消息队列创建响应：返回队列是否创建成功；
消息队列删除请求：删除队列中的所有元素；
消息队列删除响应：返回队列是否删除成功；
批量消息写入请求：给定队列名称和消息列表，将消息列表的消息写入，返回批量入列请求响应；
批量消息写入响应：响应为写入成功的消息的数目n，代表消息列表的前n条写入成功；
批量消息读取请求：必选项包括给定队列名称和出列(即读取)的消息数目，一个可选项为跳过前面M条读取；
批量消息读取响应：如果队列元素个数大于等于出列消息数目，则会返回出列消息数目的消息，如果小于的话，则会返回已有的消息；
批量消息删除请求：给定队列名称和删除的消息数目K，删除队列的前K条数据；
批量消息删除响应：响应为删除成功的消息的数目n，代表队列的前n条数据删除成功。
在此，客户端，例如Broker通过HBase-Client向对应的HBase-Server发送上述各请求，HBase-Server在对队列进行相应的操作之后，发送上述各对应的响应给该HBase-Client。
具体地，操作装置103对于锁成功的队列操作请求，对该队列操作请求所针对的队列进行与该队列操作请求相对应的队列操作。该操作装置103例如可以位于HBase的其中一个区域的协处理器中。例如，如图2所示，设备接入端Broker分别接入了不同用户的不同设备，Broker定时批量地通过HBase-Client，将设备发送的消息以RPC请求发送给HBase集群，HBase-Client可以该RPC请求中的信息进行寻址，寻址定位到该RPC请求的目标消息队列是在HBase的哪个region，然后将该队列操作请求发送至该region所在的Region Server上，Region Server接收到请求后，会触发部署在其上的协处理器处理该RPC请求。该协处理器例如可以是运行在Region Server端的一段代码，其可以实现自定义RPC请求处理。
优选地，所述队列操作包括以下至少任一项：
-消息队列创建；
-批量消息写入；
-批量消息删除；
-消息队列删除。
具体地，队列创建的目的主要是为了功能扩展，比如限定队列长度、获取队列创建时间等，在队列创建时，会将队列长度限制写入到queueName-0对应的行，该行对应的timestamp即为队列的创建时间。
处理批量消息写入请求时，会为要写入的每个消息，逐一生成一个调单递增的消息ID(monotonicID)。以queueName+monotonicID作为该消息的行键(RowKey)，以下均以RowKey表示，消息体作为value，构建出HBase的一行，这样批量消息写入请求就转换为HBase多行的写入。将构造的行批量提交给HBase就实现了批量的顺序写入，写入成功后，最大消息ID会随之增加。进一步，作为功能扩展，可以根据创建队列时给定的长度限制，控制队列消息数目，当消息数目达到最大长度限制时，将无法继续写入。
由前述批量消息写入的描述可知，批量消息删除可以转换为HBase多行的删除。只需要构建出要删除的行的RowKey，提交批量删除行的操作即可。RowKey的构建以queueName+最小消息ID为起点，逐步递增构建消息ID，以queueName+最小消息ID+要删除的消息数目为终点，就构建需要删除的一系列RowKey，最后批量提交给HBase进行删除。
消息队列删除操作不仅要删除队列存储的消息，还要删除保留的配置项。由于配置项与最小消息ID间可能有很大距离，因此，首先用scan操作，以queueName-0为起点，以queueName-最大消息ID为终点，扫描出队列中所有的元素(行)，进而得到每个行的RowKey，最终批量提交删除这些RowKey对应的行。
优选地，所述队列操作还包括批量读取。由于知道队列的最小消息ID，并且消息ID是单调连续的，所以在批量读取时，通过给定RowKey的起点及终点，用scan命令进行范围读，以queueName+最小消息ID为RowKey起点，以RowKey起点+要读取的数量为RowKey终点，即可取得起点和终点范围内的所有消息。如果是跳过前N条数据的读取，则起点ID为最小消息ID加上N即可。
优选地，所述队列操作还包括队列状态获取，获取该队列当前的消息数目、队列创建时间等状态信息。
本领域技术人员应能理解，上述队列操作仅为举例，其他现有或今后可能出现的队列操作，如可适用于本发明，也应包含在本发明保护范围以内，并在此以引用的方式包含于此。
解除装置104在所述队列操作完成后，解除所述队列锁。
具体地，在该队列操作完成之后，其对应的线程可以解除队列锁，使得队列锁重新回归未加锁的状态，供其他队列操作请求继续竞争，通过队列锁可以保证请求是顺序执行的。
调度装置105调度所述竞争装置、操作装置和解除装置重复执行其操作，直至完成对所述多个队列操作请求的执行，以实现基于HBase的强有序队列操作。
具体地，调度装置105调度前述竞争装置102、操作装置103和解除装置104重复执行其操作，即，多个队列操作请求同时且针对同一队列，在其中一个竞争队列锁成功的队列操作请求完成其对应的队列操作之后，该多个队列操作请求中剩余的多个队列操作请求继续竞争队列锁，剩余的队列操作请求中又有一个竞争成功，继续执行对应的队列操作，完成后解除队列锁；然后剩下的队列操作请求再一次竞争队列锁，重复上述操作，直至完成对该多个队列操作请求的执行，从而保证多个队列操作请求是顺序执行的，实现基于HBase的强有序队列操作。
在此，有序装置1获取多个客户端发送的队列操作请求，其中，所述队列操作请求所针对的队列位于HBase分布式数据库中，若多个队列操作请求同时且针对同一队列，对所述多个队列操作请求进行竞争队列锁，对于锁成功的队列操作请求，对所述队列进行与所述队列操作请求相对应的队列操作，所述队列操作完成后，解除所述队列锁，重复执行上述步骤，直至完成对所述多个队列操作请求的执行，以实现基于HBase的强有序队列操作。与现有技术相比，有序装置1具有高性能强有序、高可用性、支持海量设备和数据不容易丢失等优点，可应用于云的物联网接入服务，性能好、可靠性高、水平扩展性强，满足海量用户和设备的接入。
更优选地，所述队列操作包括批量消息写入，其中，该有序装置1还包括确定装置(未示出)。该确定装置基于所述队列操作请求，为所述队列的每个消息分配一个单调递增的消息ID，再结合用户ID和用户设备ID，确定每个消息所对应的RowKey。
具体地，确定装置例如位于HBase的RegionServer端的协处理器中，该确定装置基于队列操作请求，如该队列操作请求中的批量消息写入请求，为每个消息分配一个单调递增的消息ID，例如，当有序装置1接收到批量消息写入请求，该确定装置即调用HBase内存中的ID生成器为该请求中携带的每个消息分配一个单调递增的消息ID，随后，该确定装置再结合用户ID和用户设备ID，确定每个消息对应的RowKey。在此，该用户ID和用户设备ID可以是用户ID和用户设备ID本身，也可以是经变化过后的用户ID和用户设备ID。
在此，由于HBase不提供队列(queue)功能，因此，可以先在HBase的一张表上，逻辑分割出不同的队列，或称虚拟队列(virtual queue)，这些队列分属于不同用户的不同设备。队列的逻辑分割，主要通过HBase的RowKey设计来实现。每个队列属于特定用户的特定设备，是一一对应的关系，以用户ID(userId)标识一个用户，以用户设备ID(clientId)标识一个设备，那么userId+clientId可唯一标识一个队列。每个队列中有许多消息，消息是有序的，因此，可以用一个单调递增的消息ID(monotonicID)来标识每条消息，这个消息ID只需要在设备范围下递增即可，即userId+clientId+monotonicId作为RowKey即可在一行里唯一标识一条消息，消息的内容存储在RowKey对应的值当中。在此，用户ID和用户设备ID还可以进行一定的变化，例如，对RowKey进行归一化和离散化的优化。
归一化：userId和monotonicId其长度是固定的，但clientId作为设备ID，由连接设备指定，其长度往往是不确定的，进而导致RowKey的长度是不定长的。为了存储上的性能优化，可以对RowKey的长度做归一化处理。方法是为每个clientId分配一个userId下唯一的uniqueClientId，是一个长整形数字，以uniqueClientId代替clientId作为RowKey的一部分，这样RowKey的长度就是固定的了。
离散化：由于HBase的RowKey是按照字节序递增排列的，所以userId相同的RowKey在顺序上会排列在一起，也就意味着同一个用户的队列大都会分布在同一块区域(region)上，这样有两个缺点，首先是热点问题，用户所有的请求都访问同一块区域，会导致区域过热，吞吐量有限。其次是可靠性问题，如果该区域出现问题，会影响用户几乎所有设备。为了避免这些情况，可以对RowKey做离散化处理，方法是将uniqueClientId和userId调换顺序，并翻转uniqueClientId的字节顺序，这样同一个用户的队列会分散开，位于不同区域，而同一个队列的消息仍然会顺序排列。
因此，最终的RowKey设计可以优化为：
Reverse(UniqueClinetID)+UserID+MonotonicID
其中，Reverse(UniqueClinetID)+UserID可以用来定义队列名称queueName，该队列名称可唯一标识一个队列。
在此，HBase中RegionServer的协处理器，或进一步地，其上的确定装置，为每条消息确定一个优化的RowKey，更进一步地有利于对消息队列的强有序队列操作。
优选地，该有序装置1还包括缓存装置(未示出)。该缓存装置缓存所述队列的最小消息ID和最大消息ID，当所述队列操作包括批量消息写入时，所述最大消息ID进行递增，当所述队列操作包括批量消息删除时，所述最小消息ID递增。
具体地，由于队列里的每个消息的消息ID是顺序递增的，因此，缓存装置可以缓存队列的最小消息ID和最大消息ID，这样，当消息写入时，最大消息ID递增；当消息删除时，最小消息ID递增，保证了消息的有序性。
更优选地，该有序装置1还包括读取装置(未示出)。若所述缓存失效，该读取装置利用HBase的扫描操作，读取所述队列中最小RowKey的一行和最大RowKey的一行，其中，所述RowKey中的消息ID对应所述队列的最小消息ID和最大消息ID。
具体地，当前述缓存装置所缓存的该队列的最小消息ID和最大消息ID失效时，读取装置可以利用HBase的扫描(scan)操作，读取该队列里最小RowKey的一行和最大RowKey的一行，RowKey里的monotonicID就对应了当前队列的最小消息ID和最大消息ID。由于消息ID是连续的，因此，队列的长度也可以通过最大消息ID和最小消息ID计算得出。
在此，通过对队列的最小消息ID和最大消息ID的缓存，或者通过HBase的scan操作以获得当前队列的最小消息ID和最大消息ID，保证对单次批量操作而言，批量写入/删除的消息是强有序的。因此，强有序可以包括两个方面，一是对单次批量操作而言，批量写入/删除的消息是有顺序性保证的；二是对竞争批量操作而言，用队列锁保证竞争情况下的有序性。
优选地，该有序装置1还包括分裂装置(未示出)。该分裂装置根据所述Rowkey的前两个字节，分裂HBase的区域。
具体地，随着队列数和消息数目的增多，HBase会在水平方向进行切分，即region(区域)分裂成多个region，在此，分裂装置根据所述Rowkey的前两个字节，分裂HBase的区域，使得RowKey前两个字节相同的消息分配在同一个region，保证了一个队列的所有数据会只分布在一个region上。在此，分裂装置控制region分裂有两个方面的优点，首先，一个队列的请求定位只会到一个region上，而该region包含队列所有的数据，可以满足任何数据操作；其次，在region分裂后，不同region经过平衡会分布在不同的机器上，系统是分布式的，可横向扩展的。图3示出了当region分裂后，不同的队列位于不同region，队列操作请求会发送到不同的机器上。
优选地，所述客户端对来自各个对应用户设备的数据进行缓存，定时和/或定量地根据缓存后的数据，生成所述队列操作请求。
具体地，客户端，如前所述的Broker，对来自各个对应用户设备的数据进行缓存，再定时和/或定量地根据缓存后的数据，生成队列操作请求来发送给有序装置1。以批量消息写入场景为例，Broker会缓存接受的数据，将缓存的数据聚合，如以多个数据构建出一个批量消息写入的RPC请求，再通过HBase-Client将该请求发送至对应的HBase-Server。该数据聚合及请求的发送时机也是由Broker控制的，例如可以有两个触发条件：定时和定量。定量：如果缓存的数据量超过一个预定阈值时，则Broker立马发送这些数据。定时：无论数据量有多少，Broker都会每隔一个固定时间，如50毫秒，发送这些数据。在此，HBase-Client负责向HBase-Server发送请求和接收响应，而数据缓存和定时和/或定量发送的功能是由Broker来实现的。
优选地，该有序装置1还包括重塑装置(未示出)。若HBase的其中一个区域出现异常，该重塑装置通过操作日志恢复消息数据，进行HLOG重塑。
具体地，由于在消息写入时，将一个随机的磁盘IO写入，转变为一个磁盘IO的顺序写入和一个内存写入，而顺序写入和内存写入可以同时进行，总时间相当于一个顺序写入，比随机写入会快很多。这样，当HBase的其中一个区域出现异常时，重塑装置可以通过操作日志来恢复消息数据，从而进行HLOG重塑。
由于系统是分布式的，当其中一台RegionServer出现故障或者异常时，其上的Region可能会无法访问，也就意味着Region上的队列无法正常操作。在此，如图4所示，HBase采用Zookeeper(管理器)来做分布式协调与管理，RegionServer(区域服务器)会定时发送心跳至Zookeeper，HMaster(主服务器)通过Zookeeper感知RegionServer的健康情况。例如，RegionServer会在启动时注册到Zookeeper，建立session(会话)并通过定时发送心跳保持该session。当RegionServer由于长时间未发送心跳导致session超时，Zookeeper会感知到session超时并通知HMaster。默认情况下，HMaster会通知故障RegionServer终止运行，并选择另外一台或者几台正常工作的RegionServer，将故障RegionServer上的Region(s)迁移过去。在此，如果故障RegionServer还能收到通知的话，就主动退出，收不到的话也没影响，因为客户端请求也不会再到这台故障机器了。由于Region的数据都是存储在一致性的HDFS上的，有一些内存里尚未写入的数据也可以通过HLOG重塑，所以迁移过程主要是正常工作的RegionServer去回溯HLOG，并将HDFS上的数据目录迁移即可。这样当迁移完成后，受到影响的队列又可重新访问，数据也不会发生丢失。
图5示出根据本发明另一个方面的一种基于HBase的强有序队列操作的方法的流程示意图。
在步骤S501中，有序装置1获取多个客户端发送的队列操作请求，其中，所述队列操作请求所针对的队列位于HBase分布式数据库中。
具体地，客户端可以向有序装置1发送队列操作请求，如RPC请求，该客户端例如可以是Broker，或进一步包括位于该Broker中的HBase-Client组件。该有序装置1例如位于HBase-Server，或进一步地，Region Server中，通过对HBase服务端的改造，解决了现有技术中单纯依靠客户端本身的改造所不能解决的问题。在此，Broker是一个设备接入端，其可以分别接入不同用户的不同用户设备，其可以被看成消息转发器，同时也负责一些控制和管理操作。该Broker例如通过其上的HBase-Client，向对应的HBase-Server发送队列操作请求，在步骤S501中，有序装置1通过与该客户端进行交互，例如，通过一次或多次调用客户端的应用程序接口(API)或通过其他约定的通信方式，获取该客户端发送的队列操作请求。进一步地，在步骤S501中，有序装置1可以获取多个客户端所发送的队列操作请求。该队列操作请求所针对的队列位于HBase分布式数据库中。
在此，基于HBase来设计实现多租户强有序的分布式队列系统，采用了HBase作为底层系统，其可以利用HBase的region(区域)分裂特性，不同region会位于不同的RegionServer上，Region Server可以通过添加机器的方式水平扩展。在此，该region是HBase中存储和管理的基本单元。
优选地，HBase-Client可以通过来自对应Broker的队列操作请求中的信息进行寻址，寻址定位到该队列操作请求的目标消息队列是在HBase的哪个region，然后将该队列操作请求发送至该region所在的Region Server上，Region Server上的有序装置1获取该队列操作请求。
本领域技术人员应能理解，上述获取队列操作请求的方式仅为举例，其他现有或今后可能出现的获取队列操作请求的方式，如可适用于本发明，也应包含在本发明保护范围以内，并在此以引用的方式包含于此。
在步骤S502中，若多个队列操作请求同时且针对同一队列，有序装置1对所述多个队列操作请求进行竞争队列锁。
具体地，由于对于同一个队列，同一时间可能有多个队列操作请求，如消息队列创建请求、批量消息写入请求、批量消息删除请求或消息队列删除请求等，为了保证一个队列操作里的消息的有序性，对于每个队列操作请求，都可以先去获取队列锁，在步骤S502中，有序装置1可以通知该多个队列操作请求去竞争队列锁，例如，对于HBase-Client所发送的RPC请求，HBase-Server都会为每个请求分配一个线程来进行处理，多个线程去竞争该队列锁，看谁先获取到该队列锁。该队列锁是一个公平锁，具有加锁和未加锁两种状态，当其中一个线程获取到该队列锁，即锁成功，则该队列锁即是加锁状态；当该线程处理完对该队列的操作，即可以释放该队列锁，则该队列锁又变成未加锁状态。对于获取队列锁失败的队列操作请求会阻塞，当前一个操作释放锁后，请求继续进行，然后返回。因此，当请求竞争出现时，通过队列锁可以保证请求是顺序执行的。
在步骤S503中，有序装置1对于锁成功的队列操作请求，对所述队列进行与所述队列操作请求相对应的队列操作。
在此，由于HBase原生操作只支持写入PUT、读取GET、删除DELETE和扫描读Scan，无法满足队列的基本操作，因此，可以自定义针对队列的操作，操作原语是通过protobuf定义的RPC请求和响应，操作执行将由客户端发起请求，服务端处理请求后给出响应。首先定义Reverse(UniqueClinetID)+UserID为队列名称queueName，该队列名称的定义将在下文进行详细描述。该队列名称可唯一标识一个队列，对于该队列定义了如下操作：
消息队列创建请求：给定队列名称及队列最大长度限制，创建一个队列；
消息队列创建响应：返回队列是否创建成功；
消息队列删除请求：删除队列中的所有元素；
消息队列删除响应：返回队列是否删除成功；
批量消息写入请求：给定队列名称和消息列表，将消息列表的消息写入，返回批量入列请求响应；
批量消息写入响应：响应为写入成功的消息的数目n，代表消息列表的前n条写入成功；
批量消息读取请求：必选项包括给定队列名称和出列(即读取)的消息数目，一个可选项为跳过前面M条读取；
批量消息读取响应：如果队列元素个数大于等于出列消息数目，则会返回出列消息数目的消息，如果小于的话，则会返回已有的消息；
批量消息删除请求：给定队列名称和删除的消息数目K，删除队列的前K条数据；
批量消息删除响应：响应为删除成功的消息的数目n，代表队列的前n条数据删除成功。
在此，客户端，例如Broker通过HBase-Client向对应的HBase-Server发送上述各请求，HBase-Server在对队列进行相应的操作之后，发送上述各对应的响应给该HBase-Client。
具体地，在步骤S503中，有序装置1对于锁成功的队列操作请求，对该队列操作请求所针对的队列进行与该队列操作请求相对应的队列操作。该有序装置1例如可以位于HBase的其中一个区域的协处理器中。例如，如图2所示，设备接入端Broker分别接入了不同用户的不同设备，Broker定时批量地通过HBase-Client，将设备发送的消息以RPC请求发送给HBase集群，HBase-Client可以该RPC请求中的信息进行寻址，寻址定位到该RPC请求的目标消息队列是在HBase的哪个region，然后将该队列操作请求发送至该region所在的Region Server上，Region Server接收到请求后，会触发部署在其上的协处理器处理该RPC请求。该协处理器例如可以是运行在Region Server端的一段代码，其可以实现自定义RPC请求处理。
优选地，所述队列操作包括以下至少任一项：
-消息队列创建；
-批量消息写入；
-批量消息删除；
-消息队列删除。
具体地，队列创建的目的主要是为了功能扩展，比如限定队列长度、获取队列创建时间等，在队列创建时，会将队列长度限制写入到queueName-0对应的行，该行对应的timestamp即为队列的创建时间。
处理批量消息写入请求时，会为要写入的每个消息，逐一生成一个调单递增的消息ID(monotonicID)。以queueName+monotonicID作为该消息的行键(RowKey)，以下均以RowKey表示，消息体作为value，构建出HBase的一行，这样批量消息写入请求就转换为HBase多行的写入。将构造的行批量提交给HBase就实现了批量的顺序写入，写入成功后，最大消息ID会随之增加。进一步，作为功能扩展，可以根据创建队列时给定的长度限制，控制队列消息数目，当消息数目达到最大长度限制时，将无法继续写入。
由前述批量消息写入的描述可知，批量消息删除可以转换为HBase多行的删除。只需要构建出要删除的行的RowKey，提交批量删除行的操作即可。RowKey的构建以queueName+最小消息ID为起点，逐步递增构建消息ID，以queueName+最小消息ID+要删除的消息数目为终点，就构建需要删除的一系列RowKey，最后批量提交给HBase进行删除。
消息队列删除操作不仅要删除队列存储的消息，还要删除保留的配置项。由于配置项与最小消息ID间可能有很大距离，因此，首先用scan操作，以queueName-0为起点，以queueName-最大消息ID为终点，扫描出队列中所有的元素(行)，进而得到每个行的RowKey，最终批量提交删除这些RowKey对应的行。
优选地，所述队列操作还包括批量读取。由于知道队列的最小消息ID，并且消息ID是单调连续的，所以在批量读取时，通过给定RowKey的起点及终点，用scan命令进行范围读，以queueName+最小消息ID为RowKey起点，以RowKey起点+要读取的数量为RowKey终点，即可取得起点和终点范围内的所有消息。如果是跳过前N条数据的读取，则起点ID为最小消息ID加上N即可。
优选地，所述队列操作还包括队列状态获取，获取该队列当前的消息数目、队列创建时间等状态信息。
本领域技术人员应能理解，上述队列操作仅为举例，其他现有或今后可能出现的队列操作，如可适用于本发明，也应包含在本发明保护范围以内，并在此以引用的方式包含于此。
在步骤S504中，有序装置1在所述队列操作完成后，解除所述队列锁。
具体地，在该队列操作完成之后，其对应的线程可以解除队列锁，使得队列锁重新回归未加锁的状态，供其他队列操作请求继续竞争，通过队列锁可以保证请求是顺序执行的。
在步骤S505中，有序装置1重复执行步骤S502至S504中的操作，直至完成对所述多个队列操作请求的执行，以实现基于HBase的强有序队列操作。
具体地，在步骤S505中，有序装置1重复执行步骤S502至S504中的操作，即，多个队列操作请求同时且针对同一队列，在其中一个竞争队列锁成功的队列操作请求完成其对应的队列操作之后，该多个队列操作请求中剩余的多个队列操作请求继续竞争队列锁，剩余的队列操作请求中又有一个竞争成功，继续执行对应的队列操作，完成后解除队列锁；然后剩下的队列操作请求再一次竞争队列锁，重复上述操作，直至完成对该多个队列操作请求的执行，从而保证多个队列操作请求是顺序执行的，实现基于HBase的强有序队列操作。
在此，有序装置1获取多个客户端发送的队列操作请求，其中，所述队列操作请求所针对的队列位于HBase分布式数据库中，若多个队列操作请求同时且针对同一队列，对所述多个队列操作请求进行竞争队列锁，对于锁成功的队列操作请求，对所述队列进行与所述队列操作请求相对应的队列操作，所述队列操作完成后，解除所述队列锁，重复执行上述步骤，直至完成对所述多个队列操作请求的执行，以实现基于HBase的强有序队列操作。与现有技术相比，有序装置1具有高性能强有序、高可用性、支持海量设备和数据不容易丢失等优点，可应用于云的物联网接入服务，性能好、可靠性高、水平扩展性强，满足海量用户和设备的接入。
更优选地，所述队列操作包括批量消息写入，其中，该方法还包括步骤S506(未示出)。在步骤S506中，有序装置1基于所述队列操作请求，为所述队列的每个消息分配一个单调递增的消息ID，再结合用户ID和用户设备ID，确定每个消息所对应的RowKey。
具体地，有序装置1例如位于HBase的RegionServer端的协处理器中，在步骤S506中，有序装置1基于队列操作请求，如该队列操作请求中的批量消息写入请求，为每个消息分配一个单调递增的消息ID，例如，当有序装置1接收到批量消息写入请求，在步骤S506中，有序装置1即调用HBase内存中的ID生成器为该请求中携带的每个消息分配一个单调递增的消息ID，随后，在步骤S506中，有序装置1再结合用户ID和用户设备ID，确定每个消息对应的RowKey。在此，该用户ID和用户设备ID可以是用户ID和用户设备ID本身，也可以是经变化过后的用户ID和用户设备ID。
在此，由于HBase不提供队列(queue)功能，因此，可以先在HBase的一张表上，逻辑分割出不同的队列，或称虚拟队列(virtual queue)，这些队列分属于不同用户的不同设备。队列的逻辑分割，主要通过HBase的RowKey设计来实现。每个队列属于特定用户的特定设备，是一一对应的关系，以用户ID(userId)标识一个用户，以用户设备ID(clientId)标识一个设备，那么userId+clientId可唯一标识一个队列。每个队列中有许多消息，消息是有序的，因此，可以用一个单调递增的消息ID(monotonicID)来标识每条消息，这个消息ID只需要在设备范围下递增即可，即userId+clientId+monotonicId作为RowKey即可在一行里唯一标识一条消息，消息的内容存储在RowKey对应的值当中。在此，用户ID和用户设备ID还可以进行一定的变化，例如，对RowKey进行归一化和离散化的优化。
归一化：userId和monotonicId其长度是固定的，但clientId作为设备ID，由连接设备指定，其长度往往是不确定的，进而导致RowKey的长度是不定长的。为了存储上的性能优化，可以对RowKey的长度做归一化处理。方法是为每个clientId分配一个userId下唯一的uniqueClientId，是一个长整形数字，以uniqueClientId代替clientId作为RowKey的一部分，这样RowKey的长度就是固定的了。
离散化：由于HBase的RowKey是按照字节序递增排列的，所以userId相同的RowKey在顺序上会排列在一起，也就意味着同一个用户的队列大都会分布在同一块区域(region)上，这样有两个缺点，首先是热点问题，用户所有的请求都访问同一块区域，会导致区域过热，吞吐量有限。其次是可靠性问题，如果该区域出现问题，会影响用户几乎所有设备。为了避免这些情况，可以对RowKey做离散化处理，方法是将uniqueClientId和userId调换顺序，并翻转uniqueClientId的字节顺序，这样同一个用户的队列会分散开，位于不同区域，而同一个队列的消息仍然会顺序排列。
因此，最终的RowKey设计可以优化为：
Reverse(UniqueClinetID)+UserID+MonotonicID
其中，Reverse(UniqueClinetID)+UserID可以用来定义队列名称queueName，该队列名称可唯一标识一个队列。
在此，HBase中RegionServer的协处理器为每条消息确定一个优化的RowKey，更进一步地有利于对消息队列的强有序队列操作。
优选地，该方法还包括步骤S507(未示出)。在步骤S507中，有序装置1缓存所述队列的最小消息ID和最大消息ID，当所述队列操作包括批量消息写入时，所述最大消息ID进行递增，当所述队列操作包括批量消息删除时，所述最小消息ID递增。
具体地，由于队列里的每个消息的消息ID是顺序递增的，因此，在步骤S507中，有序装置1可以缓存队列的最小消息ID和最大消息ID，这样，当消息写入时，最大消息ID递增；当消息删除时，最小消息ID递增，保证了消息的有序性。
更优选地，该方法还包括步骤S508(未示出)。若所述缓存失效，在步骤S508中，有序装置1利用HBase的扫描操作，读取所述队列中最小RowKey的一行和最大RowKey的一行，其中，所述RowKey中的消息ID对应所述队列的最小消息ID和最大消息ID。
具体地，当前述步骤S507中所缓存的该队列的最小消息ID和最大消息ID失效时，在步骤S508中，有序装置1可以利用HBase的扫描(scan)操作，读取该队列里最小RowKey的一行和最大RowKey的一行，RowKey里的monotonicID就对应了当前队列的最小消息ID和最大消息ID。由于消息ID是连续的，因此，队列的长度也可以通过最大消息ID和最小消息ID计算得出。
在此，通过对队列的最小消息ID和最大消息ID的缓存，或者通过HBase的scan操作以获得当前队列的最小消息ID和最大消息ID，保证对单次批量操作而言，批量写入/删除的消息是强有序的。因此，强有序可以包括两个方面，一是对单次批量操作而言，批量写入/删除的消息是有顺序性保证的；二是对竞争批量操作而言，用队列锁保证竞争情况下的有序性。
优选地，该方法还包括步骤S509(未示出)。在步骤S509中，有序装置1根据所述Rowkey的前两个字节，分裂HBase的区域。
具体地，随着队列数和消息数目的增多，HBase会在水平方向进行切分，即region(区域)分裂成多个region，在此，在步骤S509中，有序装置1根据所述Rowkey的前两个字节，分裂HBase的区域，使得RowKey前两个字节相同的消息分配在同一个region，保证了一个队列的所有数据会只分布在一个region上。在此，有序装置1控制region分裂有两个方面的优点，首先，一个队列的请求定位只会到一个region上，而该region包含队列所有的数据，可以满足任何数据操作；其次，在region分裂后，不同region经过平衡会分布在不同的机器上，系统是分布式的，可横向扩展的。图3示出了当region分裂后，不同的队列位于不同region，队列操作请求会发送到不同的机器上。
优选地，所述客户端对来自各个对应用户设备的数据进行缓存，定时和/或定量地根据缓存后的数据，生成所述队列操作请求。
具体地，客户端，如前所述的Broker，对来自各个对应用户设备的数据进行缓存，再定时和/或定量地根据缓存后的数据，生成队列操作请求来发送给有序装置1。以批量消息写入场景为例，Broker会缓存接受的数据，将缓存的数据聚合，如以多个数据构建出一个批量消息写入的RPC请求，再通过HBase-Client将该请求发送至对应的HBase-Server。该数据聚合及请求的发送时机也是由Broker控制的，例如可以有两个触发条件：定时和定量。定量：如果缓存的数据量超过一个预定阈值时，则Broker立马发送这些数据。定时：无论数据量有多少，Broker都会每隔一个固定时间，如50毫秒，发送这些数据。在此，HBase-Client负责向HBase-Server发送请求和接收响应，而数据缓存和定时和/或定量发送的功能是由Broker来实现的。
优选地，该方法还包括步骤S510(未示出)。若HBase的其中一个区域出现异常，在步骤S510中，有序装置1通过操作日志恢复消息数据，进行HLOG重塑。
具体地，由于在消息写入时，将一个随机的磁盘IO写入，转变为一个磁盘IO的顺序写入和一个内存写入，而顺序写入和内存写入可以同时进行，总时间相当于一个顺序写入，比随机写入会快很多。这样，当HBase的其中一个区域出现异常时，在步骤S510中，有序装置1可以通过操作日志来恢复消息数据，从而进行HLOG重塑。
由于系统是分布式的，当其中一台RegionServer出现故障或者异常时，其上的Region可能会无法访问，也就意味着Region上的队列无法正常操作。在此，如图4所示，HBase采用Zookeeper(管理器)来做分布式协调与管理，RegionServer(区域服务器)会定时发送心跳至Zookeeper，HMaster(主服务器)通过Zookeeper感知RegionServer的健康情况。例如，RegionServer会在启动时注册到Zookeeper，建立session(会话)并通过定时发送心跳保持该session。当RegionServer由于长时间未发送心跳导致session超时，Zookeeper会感知到session超时并通知HMaster。默认情况下，HMaster会通知故障RegionServer终止运行，并选择另外一台或者几台正常工作的RegionServer，将故障RegionServer上的Region(s)迁移过去。在此，如果故障RegionServer还能收到通知的话，就主动退出，收不到的话也没影响，因为客户端请求也不会再到这台故障机器了。由于Region的数据都是存储在一致性的HDFS上的，有一些内存里尚未写入的数据也可以通过HLOG重塑，所以迁移过程主要是正常工作的RegionServer去回溯HLOG，并将HDFS上的数据目录迁移即可。这样当迁移完成后，受到影响的队列又可重新访问，数据也不会发生丢失。
本发明还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机代码，当所述计算机代码被执行时，如前任一项所述的方法被执行。
本发明还提供了一种计算机程序产品，当所述计算机程序产品被计算机设备执行时，如前任一项所述的方法被执行。
本发明还提供了一种计算机设备，所述计算机设备包括：
一个或多个处理器；
存储器，用于存储一个或多个计算机程序；
当所述一个或多个计算机程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如前任一项所述的方法。
需要注意的是，本发明可在软件和/或软件与硬件的组合体中被实施，例如，本发明的各个装置可采用专用集成电路(ASIC)或任何其他类似硬件设备来实现。在一个实施例中，本发明的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本发明的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本发明的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。
对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。系统权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (19)

1.一种基于HBase的强有序队列操作的方法，其中，该方法包括：
a获取多个客户端发送的队列操作请求，其中，所述队列操作请求所针对的队列位于HBase分布式数据库中；
b若多个队列操作请求同时且针对同一队列，对所述多个队列操作请求进行竞争队列锁；
c对于锁成功的队列操作请求，对所述队列进行与所述队列操作请求相对应的队列操作；
d所述队列操作完成后，解除所述队列锁；
e重复执行步骤b至d，直至完成对所述多个队列操作请求的执行，以实现基于HBase的强有序队列操作。
2.根据权利要求1所述的方法，其中，所述队列操作包括以下至少任一项：
-消息队列创建；
-批量消息写入；
-批量消息删除；
-消息队列删除。
3.根据权利要求2所述的方法，其中，所述队列操作包括批量消息写入，其中，该方法还包括：
基于所述队列操作请求，为所述队列的每个消息分配一个单调递增的消息ID，再结合用户ID和用户设备ID，确定每个消息所对应的行键。
4.根据权利要求3所述的方法，其中，该方法还包括：
缓存所述队列的最小消息ID和最大消息ID，当所述队列操作包括批量消息写入时，所述最大消息ID进行递增，当所述队列操作包括批量消息删除时，所述最小消息ID递增。
5.根据权利要求4所述的方法，其中，该方法还包括：
若所述缓存失效，利用HBase的扫描操作，读取所述队列中最小行键的一行和最大行键的一行，其中，所述行键中的消息ID对应所述队列的最小消息ID和最大消息ID。
6.根据权利要求3至5中任一项所述的方法，其中，该方法还包括：
根据所述行键的前两个字节，分裂HBase的区域。
7.根据权利要求1至6中任一项所述的方法，其中，该方法还包括：
所述客户端对来自各个对应用户设备的数据进行缓存，定时和/或定量地根据缓存后的数据，生成所述队列操作请求。
8.根据权利要求1至7中任一项所述的方法，其中，该方法还包括：
若HBase的其中一个区域出现异常，通过操作日志恢复消息数据，进行HLOG重塑。
9.一种基于HBase的强有序队列操作的有序装置，其中，该有序装置包括：
获取装置，用于获取多个客户端发送的队列操作请求，其中，所述队列操作请求所针对的队列位于HBase分布式数据库中；
竞争装置，用于若多个队列操作请求同时且针对同一队列，对所述多个队列操作请求进行竞争队列锁；
操作装置，用于对于锁成功的队列操作请求，对所述队列进行与所述队列操作请求相对应的队列操作；
解除装置，用于所述队列操作完成后，解除所述队列锁；
调度装置，用于调度所述竞争装置、操作装置和解除装置重复执行其操作，直至完成对所述多个队列操作请求的执行，以实现基于HBase的强有序队列操作。
10.根据权利要求9所述的有序装置，其中，所述队列操作包括以下至少任一项：
-消息队列创建；
-批量消息写入；
-批量消息删除；
-消息队列删除。
11.根据权利要求10所述的有序装置，其中，所述队列操作包括批量消息写入，其中，该有序装置还包括：
确定装置，用于基于所述队列操作请求，为所述队列的每个消息分配一个单调递增的消息ID，再结合用户ID和用户设备ID，确定每个消息所对应的行键。
12.根据权利要求11所述的有序装置，其中，该有序装置还包括：
缓存装置，用于缓存所述队列的最小消息ID和最大消息ID，当所述队列操作包括批量消息写入时，所述最大消息ID进行递增，当所述队列操作包括批量消息删除时，所述最小消息ID递增。
13.根据权利要求12所述的有序装置，其中，该有序装置还包括：
读取装置，用于若所述缓存失效，利用HBase的扫描操作，读取所述队列中最小行键的一行和最大行键的一行，其中，所述行键中的消息ID对应所述队列的最小消息ID和最大消息ID。
14.根据权利要求11至13中任一项所述的有序装置，其中，该有序装置还包括：
分裂装置，用于根据所述行键的前两个字节，分裂HBase的区域。
15.根据权利要求9至14中任一项所述的有序装置，其中，所述客户端对来自各个对应用户设备的数据进行缓存，定时和/或定量地根据缓存后的数据，生成所述队列操作请求。
16.根据权利要求9至15中任一项所述的有序装置，其中，该有序装置还包括：
重塑装置，用于若HBase的其中一个区域出现异常，通过操作日志恢复消息数据，进行HLOG重塑。
17.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机代码，当所述计算机代码被执行时，如权利要求1至8中任一项所述的方法被执行。
18.一种计算机程序产品，当所述计算机程序产品被计算机设备执行时，如权利要求1至8中任一项所述的方法被执行。
19.一种计算机设备，所述计算机设备包括：
一个或多个处理器；
存储器，用于存储一个或多个计算机程序；
当所述一个或多个计算机程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至8中任一项所述的方法。
CN201710526912.6A 2017-06-30 2017-06-30 一种基于HBase的强有序队列操作的方法和装置 Active CN107370797B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710526912.6A CN107370797B (zh) 2017-06-30 2017-06-30 一种基于HBase的强有序队列操作的方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710526912.6A CN107370797B (zh) 2017-06-30 2017-06-30 一种基于HBase的强有序队列操作的方法和装置

Publications (2)

Publication Number Publication Date
CN107370797A true CN107370797A (zh) 2017-11-21
CN107370797B CN107370797B (zh) 2021-07-27

Family

ID=60305925

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710526912.6A Active CN107370797B (zh) 2017-06-30 2017-06-30 一种基于HBase的强有序队列操作的方法和装置

Country Status (1)

Country Link
CN (1) CN107370797B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108984325A (zh) * 2018-07-20 2018-12-11 北京北信源信息安全技术有限公司 消息队列消费方法和装置
CN109165193A (zh) * 2018-07-27 2019-01-08 阿里巴巴集团控股有限公司 日志数据的存储方法、装置、客户端及服务器
CN112804279A (zh) * 2019-11-14 2021-05-14 北京沃东天骏信息技术有限公司 一种请求处理方法和装置
CN109617789B (zh) * 2018-12-29 2021-05-28 满帮信息咨询有限公司 会话消息的处理方法、系统、电子设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080177955A1 (en) * 2007-01-23 2008-07-24 International Business Machines Corporation Achieving Both Locking Fairness and Locking Performance with Spin Locks
CN101854302A (zh) * 2010-05-27 2010-10-06 中兴通讯股份有限公司 报文保序方法及系统
CN103631940A (zh) * 2013-12-09 2014-03-12 中国联合网络通信集团有限公司 一种应用于hbase数据库的数据写入方法及系统
CN103646073A (zh) * 2013-12-11 2014-03-19 浪潮电子信息产业股份有限公司 一种基于HBase表的条件查询优化方法
CN104537003A (zh) * 2014-12-16 2015-04-22 北京中交兴路车联网科技有限公司 一种Hbase数据库的通用高性能数据写入方法
CN105760395A (zh) * 2014-12-18 2016-07-13 华为技术有限公司 一种数据处理的方法、装置及系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080177955A1 (en) * 2007-01-23 2008-07-24 International Business Machines Corporation Achieving Both Locking Fairness and Locking Performance with Spin Locks
CN101854302A (zh) * 2010-05-27 2010-10-06 中兴通讯股份有限公司 报文保序方法及系统
CN103631940A (zh) * 2013-12-09 2014-03-12 中国联合网络通信集团有限公司 一种应用于hbase数据库的数据写入方法及系统
CN103646073A (zh) * 2013-12-11 2014-03-19 浪潮电子信息产业股份有限公司 一种基于HBase表的条件查询优化方法
CN104537003A (zh) * 2014-12-16 2015-04-22 北京中交兴路车联网科技有限公司 一种Hbase数据库的通用高性能数据写入方法
CN105760395A (zh) * 2014-12-18 2016-07-13 华为技术有限公司 一种数据处理的方法、装置及系统

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108984325A (zh) * 2018-07-20 2018-12-11 北京北信源信息安全技术有限公司 消息队列消费方法和装置
CN109165193A (zh) * 2018-07-27 2019-01-08 阿里巴巴集团控股有限公司 日志数据的存储方法、装置、客户端及服务器
CN109165193B (zh) * 2018-07-27 2022-03-04 创新先进技术有限公司 日志数据的存储方法、装置、客户端及服务器
CN109617789B (zh) * 2018-12-29 2021-05-28 满帮信息咨询有限公司 会话消息的处理方法、系统、电子设备和存储介质
CN112804279A (zh) * 2019-11-14 2021-05-14 北京沃东天骏信息技术有限公司 一种请求处理方法和装置

Also Published As

Publication number Publication date
CN107370797B (zh) 2021-07-27

Similar Documents

Publication Publication Date Title
CN106202505B (zh) 数据处理方法及其系统
CN107370797A (zh) 一种基于HBase的强有序队列操作的方法和装置
JP6165729B2 (ja) クライアント／サーバシステムの分散した複製コンテンツの強一貫性を維持するための方法およびシステム
Anderson et al. High-performance task distribution for volunteer computing
US9230002B2 (en) High performant information sharing and replication for single-publisher and multiple-subscriber configuration
US7693882B2 (en) Replicating data across the nodes in a cluster environment
CN101019105B (zh) 使用条带化来存储数据的方法及装置
CN108140009A (zh) 分布式自主式基于rdma的b树键值管理器
CN105912402B (zh) 一种基于Actor模型的调度方法及装置
US7609703B2 (en) Group communication system and method
CN105337923B (zh) 数据分发方法和系统及数据发送装置和数据接收装置
CN109739890A (zh) 数据处理方法、装置及设备
CN112102044B (zh) 一种消息队列处理高并发秒杀商品的方法、系统及装置
CN102413164A (zh) 一种基于Web的三维场景可视化编辑装置和方法
Nicolae et al. Leveraging adaptive I/O to optimize collective data shuffling patterns for big data analytics
JP6920513B2 (ja) 分散データグリッドにおける分散データ構造をサポートするためのシステムおよび方法
CN104937564B (zh) 组表格的数据冲洗
CN102779183B (zh) 数据查询的方法、设备及系统
CN102752387A (zh) 数据存储处理系统和数据存储处理方法
CN110008041A (zh) 一种消息处理方法及装置
CN109614271A (zh) 多个集群数据一致性的控制方法、装置、设备及存储介质
CN109271367A (zh) 分布式文件系统多节点快照回滚方法及系统
EP3499378B1 (en) Method and system of sharing product data in a collaborative environment
CN114553959A (zh) 基于态势感知的云原生服务网格配置按需下发方法及应用
CN113347238A (zh) 基于区块链的消息分区方法及系统、设备、存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant