WO2016206600A1 - 一种信息流数据的处理方法和装置 - Google Patents

一种信息流数据的处理方法和装置 Download PDF

Info

Publication number
WO2016206600A1
WO2016206600A1 PCT/CN2016/086876 CN2016086876W WO2016206600A1 WO 2016206600 A1 WO2016206600 A1 WO 2016206600A1 CN 2016086876 W CN2016086876 W CN 2016086876W WO 2016206600 A1 WO2016206600 A1 WO 2016206600A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
user identifier
task
information
identifier
Prior art date
Application number
PCT/CN2016/086876
Other languages
English (en)
French (fr)
Inventor
黄钊
Original Assignee
北京奇虎科技有限公司
奇智软件（北京）有限公司
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 北京奇虎科技有限公司, 奇智软件（北京）有限公司 filed Critical 北京奇虎科技有限公司
Priority to US15/739,881 priority Critical patent/US20180365254A1/en
Publication of WO2016206600A1 publication Critical patent/WO2016206600A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • 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/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • 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/55—Push-based network services

Definitions

  • the present invention relates to the technical field of computer processing, and in particular, to a method for processing information stream data and a device for processing information stream data.
  • Push mode mode allows users to quickly access feed data, but if a user has a large number of fans, each of his specific behaviors will cause a large number of push requests, which greatly increases the pressure on the server. At the peak of the push request, a large number of push requests compete with other services and services for common resources (ie, "herd effect"), and unpredictable situations occur.
  • pull mode when a user has a specific behavior (such as posting a short message), it is stored in a temporary list of feeds (only data in the near-acceptable range is saved). When the user logs in, the user pulls the feed data from the feed list according to his/her own needs.
  • the feed list generally needs to save the feed data of the last ten days or half months, which will cause a lot of pressure if the user pays attention.
  • the pressure of the database will be very general, affecting the efficiency of pulling data, and generally online users, the client will scan regularly, and will increase Adding a lot of pressure may cause delay or failure of the request.
  • the present invention has been made in order to provide a method of processing information stream data and a corresponding apparatus for processing information stream data that overcome the above problems or at least partially solve the above problems.
  • a method for processing information stream data including:
  • an apparatus for processing information stream data includes:
  • An event processing module configured to process the event according to the processing request when receiving a processing request based on an event initiated by the first user identifier, where the event has an event identifier;
  • a user identifier finding module configured to search for a second user identifier that subscribes to the information of the first user identifier; the second user identifier has a information flow list;
  • An information flow list writing module configured to write the event identifier into the information flow list
  • the event information sending module is configured to send the event information corresponding to the event identifier in the information flow list to the client corresponding to the second user identifier.
  • the event identifier of the event triggered by the first user identifier is written in the information flow list associated with the second user identifier that subscribes to the information of the first user identifier, and when the second user identifier is associated with the online state, the corresponding identifier is sent.
  • Event information through asynchronous push, the event integration and unified processing within the time range allowed by the delay, reducing the number of concurrent execution of data, greatly reducing the server pressure force.
  • the task task is executed in an orderly manner through the task queue.
  • the data recovery means at the time of the disaster occurrence is increased, and on the other hand, the task priority classification according to the time dimension is ensured.
  • the Redis database in the embodiment of the present invention supports high concurrent read and write operations, ensures timely read and write of user information, and ensures user experience.
  • FIG. 1 is a flow chart showing the steps of an embodiment of a method for processing information stream data according to an embodiment of the present invention
  • FIG. 2 shows an architectural diagram of a feed system in accordance with one embodiment of the present invention
  • FIG. 3 is a diagram showing an example of a processing flow of a daemon process according to an embodiment of the present invention
  • FIG. 4 is a block diagram showing a structure of an apparatus for processing information stream data according to an embodiment of the present invention
  • FIG. 5 is a block diagram of a computing device for performing a method of processing information stream data in accordance with the present invention
  • Figure 6 is a storage unit of program code for holding or carrying a processing method for implementing information stream data according to the present invention.
  • FIG. 1 is a flow chart showing the steps of an embodiment of a method for processing information stream data according to an embodiment of the present invention. Specifically, the method may include the following steps:
  • Step 101 When receiving a processing request based on an event initiated by the first user identifier, processing the event according to the processing request;
  • a feed is a list of the latest content posted on a website. Once a user subscribes to a feed on a website, they can receive the newly published content.
  • the feed system is an independent background asynchronous system, and provides a business entity externally, for example, a bar (a keyword based on keywords) The theme of the exchange community), blogs, Weibo and so on.
  • the Presentation Layer in the feed system is user-oriented and is characterized by an APP (Application) such as a browser, an instant messaging tool, a standalone client, and the like.
  • APP Application
  • the business layer of the feed system provides the Club API (public interface).
  • the user can log in to the APP.
  • By calling the API API of the feed system in the operation of the APP a request for processing an event is sent, and the feed is requested.
  • the system processes the event to apply these entity services, for example, posting posts in post bars, posting blog posts on blogs, posting messages on Weibo, and so on.
  • the Service Layer in the feed system provides a Common Service. When receiving a processing request from the Club API, it can process it accordingly.
  • the event may be publishing information, focusing on objects and personal behavior, and the like.
  • the feed system can store the event information of the event (such as posts posted in Post Bar, blog posts posted on blogs, messages posted on Weibo) in a database (such as relational database MySQL).
  • a database such as relational database MySQL
  • the feed system can configure an event identifier (Tid) for the event, such as the ID of the posted post, the ID of the object of interest, and the like.
  • Tid event identifier
  • Step 102 Search for a second user identifier that subscribes to the information of the first user identifier.
  • the user (the second user identifier, such as the user account, the user ID, and the like) can subscribe to other users in advance by following operations such as following and establishing a friend relationship.
  • Information such as user accounts, user IDs, etc., such as posts posted in Post Bar, blog posts posted on blogs, messages posted on Weibo, etc.
  • a user center (User Center SDK) can be accessed through a data layer, and user-related information, including a subscription relationship, is stored in the user center.
  • the subscription relationship determines a second user identifier that subscribes to the information of the first user identifier.
  • the second user identifier has a feed list, and in the feed list, information subscribed by the second user identifier may be stored.
  • step 102 may include the following sub-steps:
  • Sub-step S11 generating an event task
  • the event task may include a first user identifier, an event identifier, and an event type.
  • Sub-step S12 the event task is written into a preset task queue
  • Sub-step S13 the event task is read from the task queue by a preset daemon process
  • Sub-step S14 the second user identifier that subscribes to the information of the first user identifier is searched by the preset daemon.
  • the (Async) task queue can be called asynchronously, and an event task can be pushed to the task queue (Event Queue).
  • the Kafka system generally includes several Producers (producers, such as the service layer in the feed system), several Brokers (middleware), and several Consumers (consumers, such as daemons in the feed system).
  • Producers producers, such as the service layer in the feed system
  • Brokers middleware
  • Consumers consumers, such as daemons in the feed system.
  • a Zookeeper manages the cluster.
  • the Kafka system manages the cluster configuration through Zookeeper, elects the Leader, and rebalances when the Consumer changes.
  • Producer produces messages (event tasks), using push mode to post messages to the broker;
  • Each type of message is defined as a topic, and messages within the same topic are stored on different brokers according to a certain key and algorithm partition.
  • the Consumer uses the pull mode to subscribe to and consume messages from the corresponding topic in the Broker.
  • the message queue is stored in the form of a log file, and the Producer adds the message (event task) to the end of the existing log file, and no ID information is used for the message. Positioning relies on displacement within the file. Therefore, Consumer relies on file shift order to read messages, so there is no need to maintain complex index structures that support read-out (ie, FIFO, first-in, first-out).
  • a plurality of task queues may be set in advance, and the task events of each task queue are the same event type, and when the event task is pushed, the event task may be written into a match with the event type.
  • the daemon can be pre-deployed.
  • the daemon judges whether it receives the termination signal (Stop?) transmitted by the outside world. If not (N), it continues the task loop mode. If it is (Y), it stops creating the child process (Task Thread) and judges the current The task of the child SolidWorks is completed (Task is Clear?). If not (N), the task of the current child process (Task Thread) is completed. If it is (Y), the process is terminated (Stop).
  • the daemon removes the task from the task queue, and the task is marked as being moved out in the queue. If the queue is empty, the null data is obtained, and the daemon enters a short sleep.
  • the daemons deploying different servers can periodically obtain event tasks from the task queue, and the event mediation (Eevnt Mediator) invokes the daemon process according to the event type (Event Type).
  • Event Type the event type
  • the child thread executes different operations and executes different policies for different event types to control the priority level of the event task.
  • the information of the child thread of the Event Process is maintained in the Thread List.
  • the read frequency may be preset for each event type, and the preset daemon may read the read queue from the task queue in a first-in-first-out manner according to a read frequency set for the event type. Event task.
  • the event type has a priority, and the read frequency of the first event type is higher than the read frequency of the second event type;
  • the first event type is an event type with a higher priority than the second event type
  • the second event type is an event type with a lower priority than the first event type.
  • the read frequency of the event type with higher priority is higher than the read frequency of the event type with lower priority.
  • the daemon process searches for a second user identifier that subscribes to the information of the first user identifier.
  • the daemon process finds the subscribed third user identifier.
  • the parameters such as the real-time and stability are determined by the daemon to sleep when different task events are consumed, and the number of task events in the queue is obtained.
  • the embodiment of the present invention performs an event task in an orderly manner through a task queue.
  • a time dimension FIFO consumption event task based on a data backup mechanism of a task queue of a system such as Kafka, when a program abnormality occurs, a part of the extracted data is not obtained.
  • the corresponding task can be retrieved from the backup of the queue according to the time period in which the abnormality occurs, and the data recovery method when the disaster occurs is increased; on the other hand, the FIFO consumption event task according to the time dimension ensures the acquisition event.
  • the orderly execution of tasks ensures the prioritization of event tasks by time dimension.
  • Step 103 Write the event identifier into the information flow list.
  • the event identifier is written by a preset daemon to a list of information streams stored in the Redis database.
  • the daemons are deployed on multiple online servers, and the daemons are generally independent and uncoupled.
  • the event task is acquired from a task queue at the same time, and the synchronous serial mode of the task queue based on the task queue can ensure the orderly removal of the event task.
  • the Redis supporting the high concurrent application scenario is used as the storage medium, and the data is continuously filled into the user's FeedList.
  • Redis is a non-relational database that supports high concurrency. Compared with the traditional relational database, it is characterized by fast data reading and writing speed, and can reach more than 50,000 concurrently per second. It is suitable for high concurrent business scenarios and reduces high concurrency. Performance bottlenecks caused by data storage, and support for asynchronous persistence, which is more reliable than MemCache (distributed cache system) in disaster recovery and storage security.
  • MemCache distributed cache system
  • the Redis database in the embodiment of the present invention supports high concurrent read and write operations, ensures timely read and write of user information, and ensures user experience.
  • Step 104 Send event information corresponding to the event identifier in the information flow list to the client corresponding to the second user identifier.
  • the event information corresponding to the event identifier is sent to the client corresponding to the second user identifier according to the time sequence of the event identifier in the information flow list. end.
  • the user when the user logs in online, the user obtains the feed stream information in chronological order from the feed list FeedList.
  • event information corresponding to the event identifier may be extracted from a database (such as a relational database MySQL) and sent to the client.
  • a database such as a relational database MySQL
  • Feed stream information is machine readable so that information can be passed between computers without human intervention.
  • a browser plug-in, a client application called “reader” or an API converts the source code into human-readable text for presentation to the user.
  • the event identifier of the event triggered by the first user identifier is written in the information flow list associated with the second user identifier that subscribes to the information of the first user identifier, and when the second user identifier is associated with the online state, the corresponding identifier is sent.
  • Event information through asynchronous push, performs event integration and unified processing within the time allowed by delay, which reduces the number of concurrent execution of data and greatly reduces server pressure.
  • FIG. 4 is a structural block diagram of an embodiment of a device for processing information stream data according to an embodiment of the present invention, which may specifically include the following modules:
  • the event processing module 401 is configured to process the event according to the processing request when receiving a processing request based on an event initiated by the first user identifier, where the event has an event identifier;
  • the user identifier finding module 402 is configured to search for a second user identifier that subscribes to the information of the first user identifier; the second user identifier has a information flow list;
  • the information flow list writing module 403 is configured to write the event identifier into the information flow list
  • the event information sending module 404 is configured to send the event information corresponding to the event identifier in the information flow list to the client corresponding to the second user identifier.
  • the event processing module 401 is further configured to:
  • the event information of the event is stored in a database.
  • the user identifier finding module 402 may be further configured to:
  • the event task includes a first user identifier and an event identifier
  • a second user identifier that subscribes to the information of the first user identifier is searched by a preset daemon.
  • the event task may further include an event type; the user identifier finding module 402 may further be configured to:
  • the event task is written into a preset task queue that matches the event type.
  • the user identifier finding module 402 may be further configured to:
  • the event task is read from the task queue in a first-in-first-out manner by a preset daemon process according to a read frequency set for the event type.
  • the event type may have a priority, a reading frequency of the first event type is higher than a reading frequency of the second event type;
  • the first event type is an event type with a higher priority than the second event type
  • the second event type is an event type with a lower priority than the first event type.
  • the event task may further include an event type; the user identifier finding module 402 may further be configured to:
  • the daemon process searches for a second user identifier that subscribes to the information of the first user identifier.
  • the information flow list writing module 403 may be further configured to:
  • the event identifier is written by the preset daemon to the list of streams stored in the Redis database.
  • the event information sending module 404 is further configured to:
  • the event information corresponding to the event identifier is sent to the client corresponding to the second user identifier according to the time sequence of the event identifier in the information flow list.
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • modules in the devices of the embodiments can be adaptively changed and placed in one or more devices different from the embodiment.
  • the modules or units or components of the embodiments may be combined into one module or unit or component, and further they may be divided into a plurality of sub-modules or sub-units or sub-components.
  • any combination of the features disclosed in the specification, including the accompanying claims, the abstract and the drawings, and any methods so disclosed, or All processes or units of the device are combined.
  • Each feature disclosed in this specification (including the accompanying claims, the abstract and the drawings) may be replaced by alternative features that provide the same, equivalent or similar purpose.
  • the various component embodiments of the present invention may be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof.
  • Those skilled in the art should It is understood that some or all of the functionality of some or all of the components of the processing device for information flow data in accordance with embodiments of the present invention may be implemented in practice using a microprocessor or digital signal processor (DSP).
  • DSP digital signal processor
  • the invention can also be implemented as a device or device program (e.g., a computer program and a computer program product) for performing some or all of the methods described herein.
  • Such a program implementing the invention may be stored on a computer readable medium or may be in the form of one or more signals. Such signals may be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.
  • Figure 5 illustrates a computing device for performing a method of processing information flow data in accordance with the present invention.
  • the computing device conventionally includes a processor 510 and a program product or readable medium in the form of a memory 520.
  • Memory 520 can be an electronic memory such as a flash memory, EEPROM (Electrically Erasable Programmable Read Only Memory), EPROM, or ROM.
  • Memory 520 has a memory space 530 for program code 531 for performing any of the method steps described above.
  • storage space 530 for program code may include various program code 531 for implementing various steps in the above methods, respectively.
  • These program codes can be read from or written to one or more program products.
  • These program products include program code carriers such as memory cards.
  • Such a program product is typically a portable or fixed storage unit as described with reference to FIG.
  • the storage unit may have storage segments, storage spaces, and the like that are similarly arranged to memory 520 in the computing device of FIG.
  • the program code can be compressed, for example, in an appropriate form.
  • the storage unit includes readable code 531', ie, code that can be read by a processor, such as 510, that when executed by a computing device causes the computing device to perform various steps in the methods described above .
  • the embodiment of the invention discloses a method for processing information flow data, including:
  • step of processing the event according to the processing request comprises:
  • the event information of the event is stored in a database.
  • A3 The method as described in A1 or A2, wherein the step of searching for a second user identifier that subscribes to the information of the first user identifier comprises:
  • the event task includes a first user identifier and an event identifier
  • a second user identifier that subscribes to the information of the first user identifier is searched by a preset daemon.
  • the step of writing the event task into a preset task queue includes:
  • the event task is written into a preset task queue that matches the event type.
  • the method of A4, wherein the step of reading the event task from the task queue by a preset daemon process comprises:
  • the event task is read from the task queue in a first-in-first-out manner by a preset daemon process according to a read frequency set for the event type.
  • A6 The method of A5, wherein the event type has a priority, a reading frequency of the first event type is higher than a reading frequency of the second event type;
  • the first event type is an event type with a higher priority than the second event type
  • the second event type is an event type with a lower priority than the first event type.
  • A7 The method of A3, wherein the event task further comprises an event type;
  • the step of searching, by the daemon, the second user identifier that subscribes to the information of the first user identifier includes:
  • the daemon process searches for a second user identifier that subscribes to the information of the first user identifier.
  • the event identifier is written by the preset daemon to the list of streams stored in the Redis database.
  • the step of sending the event information corresponding to the event identifier in the information flow list to the client corresponding to the second user identifier comprises:
  • the event information corresponding to the event identifier is sent to the client corresponding to the second user identifier according to the time sequence of the event identifier in the information flow list.
  • the embodiment of the invention further discloses a device for processing information flow data, comprising:
  • An event processing module configured to process the event according to the processing request when receiving a processing request based on an event initiated by the first user identifier, where the event has an event identifier;
  • a user identifier finding module configured to search for a second user identifier that subscribes to the information of the first user identifier; the second user identifier has a information flow list;
  • An information flow list writing module configured to write the event identifier into the information flow list
  • the event information sending module is configured to send the event information corresponding to the event identifier in the information flow list to the client corresponding to the second user identifier.
  • the event information of the event is stored in a database.
  • the event task includes a first user identifier and an event identifier
  • a second user identifier that subscribes to the information of the first user identifier is searched by a preset daemon.
  • the event task is written into a preset task queue that matches the event type.
  • the event task is read from the task queue in a first-in-first-out manner by a preset daemon process according to a read frequency set for the event type.
  • the first event type is an event type with a higher priority than the second event type
  • the second event type is an event type with a lower priority than the first event type.
  • the daemon process searches for a second user identifier that subscribes to the information of the first user identifier.
  • the event identifier is written by the preset daemon to the list of streams stored in the Redis database.
  • the event information sending module is further configured to:
  • the event information corresponding to the event identifier is sent to the client corresponding to the second user identifier according to the time sequence of the event identifier in the information flow list.

Abstract

本发明实施例提供了一种信息流数据的处理方法和装置，所述方法包括：当接收到基于第一用户标识发起的一事件的处理请求时，按照所述处理请求处理所述事件，所述事件具有事件标识；查找订阅所述第一用户标识的信息的第二用户标识；所述第二用户标识具有关联的信息流列表；将所述事件标识写入所述信息流列表中；将所述信息流列表中事件标识对应的事件信息发送至所述第二用户标识对应的客户端。本发明实施例通过异步推送在延迟允许的时间范围内进行事件整合统一处理，降低了数据的并发执行数，大大减轻了服务器压力。

Description

一种信息流数据的处理方法和装置 技术领域
本发明涉及计算机处理的技术领域，特别是涉及一种信息流数据的处理方法和一种信息流数据的处理装置。
背景技术
随着网络科技的发展，目前许多产品，例如，博客(Blog)、SNS(Social Network Site，社会性网络服务)、RSS(Really Simple Syndication，简易信息聚合)等等，引入了用户关注功能，用户可以在应用中查看到关注对象的历史行为。
在这些产品中，大多应用了应用到了Feed(信息流)系统，通常需要通过推(push)模式或拉(pull)模式发布Feed(信息流)数据。
在推(push)模式中，需要为每一个用户维护一张Feed(信息流)列表，当一个用户发生了特定行为(如发表一条短消息)，系统会往关注他的用户(俗称“粉丝”)的Feed(信息流)列表中推送数据。
推(push)模式模式虽然可以让用户快捷获取Feed(信息流)数据，但是，如果一个用户拥有大量的粉丝，这样他的每一个特定行为都会造成海量的推送请求，这样大大增加了服务器的压力，在推送请求的高峰时段，大量的推送请求与别的业务和服务争抢公用资源(即“羊群效应”)，发生不可预估的情况。
在拉(pull)模式中，当一个用户发生了特定行为(如发表一条短消息)时，会将其存储到一个临时的Feed(信息流)列表中(只保存近期可接受范围的数据)，用户在登陆时根据自身需要从Feed(信息流)列表拉取Feed(信息流)数据。
拉(pull)模式虽然设计简单，节省存储空间，但是，Feed(信息流)列表一般需要保存最近十天或者半个月的Feed(信息流)数据，会产生很大的压力，如果用户关注了大量的对象，数据库的压力就会非常大会，影响拉取数据时的效率问题，而且一般在线的用户，客户端都会定期扫描，又会增 加很大的压力，可能造成请求延迟或失败的现象发生。
发明内容
鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种信息流数据的处理方法和相应的一种信息流数据的处理装置。
依据本发明的一个方面，提供了一种信息流数据的处理方法，包括：
当接收到基于第一用户标识发起的一事件的处理请求时，按照所述处理请求处理所述事件，所述事件具有事件标识；
查找订阅所述第一用户标识的信息的第二用户标识；所述第二用户标识具有关联的信息流列表；
将所述事件标识写入所述信息流列表中；
将所述信息流列表中事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
根据本发明的另一方面，提供了一种信息流数据的处理装置，包括：
事件处理模块，配置为在接收到基于第一用户标识发起的一事件的处理请求时，按照所述处理请求处理所述事件，所述事件具有事件标识；
用户标识查找模块，配置为查找订阅所述第一用户标识的信息的第二用户标识；所述第二用户标识具有信息流列表；
信息流列表写模块，配置为将所述事件标识写入所述信息流列表中；
事件信息发送模块，配置为将所述信息流列表中事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
本发明实施例将基于第一用户标识触发的事件的事件标识写入订阅第一用户标识的信息的第二用户标识关联的信息流列表中，在第二用户标识关联在线状态时，发送相应的事件信息，通过异步推送在延迟允许的时间范围内进行事件整合统一处理，降低了数据的并发执行数，大大减轻了服务器压 力。
本发明实施例通过任务队列有序执行事件任务，一方面，增加的灾难发生时的数据可恢复手段，另一方面，保证了按时间维度的任务优先级区分。
本发明实施例中的Redis数据库支持高并发的读写操作，保证了用户信息读写更新的及时性，保证了用户体验。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1示出了根据本发明一个实施例的一种信息流数据的处理方法实施例的步骤流程图；
图2示出了根据本发明一个实施例的一种Feed系统的架构图；
图3示出了根据本发明一个实施例的一种守护进程的处理流程示例图；图4示出了根据本发明一个实施例的一种信息流数据的处理装置实施例的结构框图；
图5是用于执行根据本发明的信息流数据的处理方法的计算设备的框图；
图6是用于保持或者携带实现根据本发明的信息流数据的处理方法的程序代码的存储单元。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地 理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
参照图1，示出了根据本发明一个实施例的一种信息流数据的处理方法实施例的步骤流程图，具体可以包括如下步骤：
步骤101，当接收到基于第一用户标识发起的一事件的处理请求时，按照所述处理请求处理所述事件；
Feed(信息流)是指网站上发布的最新内容的列表，用户订阅网站上的Feed(信息流)后，就可以接收新发布的内容了。
参加图2，示例了本发明实施例的一种Feed系统的架构图，如图2所示，该Feed系统是一个独立的后台异步系统，对外提供业务实体，例如，贴吧(一种基于关键词的主题交流社区)、博客、微博等等。
Feed系统中的表现层(Preseentation Layer)面向用户，其表征为APP(Application，应用程序)，如浏览器、即时通讯工具、独立的客户端等等。
Feed系统中的对外业务层(Business Layer)提供Club API(公共接口)，用户可以在APP中登录，通过在APP的操作，调用Feed系统系统的Club API，发送某个事件的处理请求，请求Feed系统处理该事件，以应用这些实体业务，例如，在贴吧发布帖子、在博客发布博文、在微博发布消息等等。
Feed系统中的服务层(Service Layer)提供Common Service(公共服务)，当接收到来自Club API的处理请求时，则可以进行相应的处理。
在具体实现中，该事件可以为发布信息、关注对象和个人的一些行为等等。
对于发布信息，Feed系统可以将该事件的事件信息(如在贴吧发布的帖子、在博客发布的博文、在微博发布的消息)存储到数据库(如关系型数据库MySQL)中。
为了识别该事件，Feed系统可以为该事件配置事件标识(Tid)，如发布的帖子的ID、关注对象的ID等等。
步骤102，查找订阅所述第一用户标识的信息的第二用户标识；
应用本发明实施例，用户(第二用户标识表征，如用户账号、用户ID等)可以预先通过关注、建立好友关系等操作，订阅其他用户(第一用户标 识表征，如用户账号、用户ID等)的信息，如在贴吧发布的帖子、在博客发布的博文、在微博发布的消息等等。
在具体实现中，如图2所示，在Feed系统中可以通过数据访问层(Database Layer)访问用户中心(User Center SDK)，在用户中心存储了与用户相关的信息，其中包括订阅关系，按照该订阅关系，确定订阅了第一用户标识的信息的第二用户标识。
该第二用户标识具有信息流列表(Feed List)，在信息流列表(Feed List)中，可以存储该第二用户标识所订阅的信息。
在本发明的一种优选实施例中，步骤102可以包括如下子步骤：
子步骤S11，生成事件任务；
其中，事件任务可以包括第一用户标识、事件标识、事件类型；
子步骤S12，将所述事件任务写入预置的任务队列中；
子步骤S13，由预置的守护进程从所述任务队列中读取所述事件任务；
子步骤S14，由预置的守护进程查找订阅所述第一用户标识的信息的第二用户标识。
如图2所示，在Feed系统中，可以异步调用(Async)任务队列，向任务队列(Event Queue)推送一个事件任务。
以Kafka系统为例，Kafka系统中一般包含若干个Producer(生产者，如Feed系统中的服务层)，若干个Broker(中间件)，若干Consumer(消费者，如Feed系统中的守护进程)以及一个Zookeeper管理集群。
Kafka系统通过Zookeeper管理集群配置，选举Leader(领导者)，以及在Consumer发生变化时进行rebalance(平衡)。
Producer生产消息(事件任务)，使用push模式将消息发布到Broker；
每个类型的消息(事件任务)被定义为topic(主题)，同一topic内部的消息按照一定的key和算法被分区(partition)存储在不同的Broker上.
Consumer使用pull模式从Broker中相应的topic订阅并消费消息。
在实际应用中，在Broker中，消息队列是以log文件的形式存储，Producer将消息(事件任务)添加到既有的log文件尾部，没有ID信息用于消息的 定位，依靠文件内的位移，因此，Consumer依靠文件位移顺序读取消息，这样也就不需要维护复杂的支持随即读取的索引结构(即FIFO，先进先出)。
在本发明实施例中，可以预先设置多个任务队列，每个任务队列的任务事件同一事件类型，则在推送事件任务时，可以将所述事件任务写入与所述事件类型匹配的、预置的任务队列中。应用本发明实施例，可以预先部署守护进程。
如图3所示，在Feed系统中，首先启动守护进程(Start Daemon)，进入任务循环模式(Process loop)，根据配置参数定时地创建子进程(Task Thread)，从任务队列中获取任务事件(Get Task From Event Queue)，解析任务事件的事件类型(Task Type 1、Task Type 2...)，异步调用(Async)子进程(Task Thread)执行该事件任务(Task TypeN Count＝＝Task TypeN Execute Count)。
守护进程判断是否接收到外界传送的终止信号(Stop？)，若否(N)，则继续任务循环模式(Process loop)，若是(Y)，则停止创建子进程(Task Thread)，判断当前的子进程(Task Thread)的任务完成(Task is Clear？)，若否(N)，则等待当前的子进程(Task Thread)的任务完成，若是(Y)，则结束守护进程(Stop)。
需要说明的是，守护进程从任务队列中取出任务，该任务就会在队列中被标记为移出，如果队列为空，则取到的是空数据，守护进程会进入短暂休眠。则在发明实施例中，如图2所示，部署不同服务器的守护进程可以定时从任务队列中获取事件任务，由事件中介(Eevnt Mediator)根据事件类型(Event Type)，调用守护进程(Event Process)的子线程执行不同的操作，对不同的事件类型执行不同的策略，这样来控制事件任务的优先级别。
其中，守护进程(Event Process)的子线程的信息维护在线程列表(Thread List)中。
针对每种事件类型可以预先设定读取频率，则可以由预置的守护进程按照对所述事件类型设定的读取频率，从所述任务队列中按照先进先出的方式读取所述事件任务。
进一步而言，所述事件类型具有优先级，第一事件类型的读取频率，高于，第二事件类型的读取频率；
其中，第一事件类型为优先级高于第二事件类型的事件类型；
第二事件类型为优先级低于第一事件类型的事件类型。
即，优先级较高的事件类型的读取频率，高于，优先级较低的事件类型的读取频率。当所述事件类型为发布型时，由所述守护进程查找订阅所述第一用户标识的信息的第二用户标识。
针对用户的发帖、发微博、发博客等发布行为，当用户发布了信息，可以往他的粉丝的FeedList中推送，这种并非要求高实时性，而且粉丝的数量不可控，所以偏向保证处理的稳定性，读取频率较低。
当所述事件类型为订阅型时，由所述守护进程查找订阅的第三用户标识。
针对用户的关注行为，当用户关注了对象之后，可以往自己的FeedList中看到对象的历史信息行为，所以这种任务的处理是要求实时性比较高，读取频率较高。
根据上述不同的业务场景，分别从实时性，稳定性等维度来决定了守护进程在消费不同任务事件时休眠的时间，获取队列中任务事件的数量等参数。
本发明实施例通过任务队列有序执行事件任务，一方面，按照时间维度的FIFO消费事件任务，基于Kafka等系统的任务队列的数据备份机制，当出现程序异常时，导致一部分被取出的数据未被解析，可以根据异常出现的时间段从队列的备份中取出相应的任务进行解析，增加的灾难发生时的数据可恢复手段；另一方面，按照时间维度的FIFO消费事件任务，保证了获取事件任务的有序进行，保证了按时间维度的事件任务优先级区分。
步骤103，将所述事件标识写入所述信息流列表中；
在具体实现中，由预置的守护进程将所述事件标识写入存储在Redis数据库中的信息流列表。
守护进程分别部署在多台线上服务器中，守护进程之间一般是独立无耦 合的，同时向一个任务队列获取事件任务，基于任务队列移出任务的同步串行方式可以保证事件任务的有序移出。
在本发明实施例中，为了保证数据处理的及时性，因此，使用支持高并发应用场景的Redis作为存储介质，不断往用户的FeedList中填充数据。
Redis是一种支持高并发的非关系数据库，相对于传统的关系型数据库，特点是数据读写速度快，每秒并发可以达到5万以上，适合高并发业务场景的应用，减小高并发情况下数据存储带来的性能瓶颈，并且支持异步持久化功能，在灾难恢复和存储安全上比MemCache(分布式的高速缓存系统)可靠。
本发明实施例中的Redis数据库支持高并发的读写操作，保证了用户信息读写更新的及时性，保证了用户体验。
步骤104，将所述信息流列表中事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
在具体实现中，当所述第二用户标识关联在线状态时，按照所述信息流列表中事件标识的时间顺序，将所述事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
即当用户在APP登录上线后，从自己的信息流列表FeedList中按时间顺序获取Feed流信息。
进一步而言，在Feed系统中，可以从数据库(如关系型数据库MySQL)中提取事件标识对应的事件信息，发送至客户端。
Feed流信息是机器可读的，这样不用人工干预就可以在计算机之间传递信息。浏览器插件、称为“读者”的客户端应用程序或者API会把源代码转换成人工可读的文本，展示给用户。
本发明实施例将基于第一用户标识触发的事件的事件标识写入订阅第一用户标识的信息的第二用户标识关联的信息流列表中，在第二用户标识关联在线状态时，发送相应的事件信息，通过异步推送在延迟允许的时间范围内进行事件整合统一处理，降低了数据的并发执行数，大大减轻了服务器压力。
对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。
参照图4，示出了根据本发明一个实施例的一种信息流数据的处理装置实施例的结构框图，具体可以包括如下模块：
事件处理模块401，配置为在接收到基于第一用户标识发起的一事件的处理请求时，按照所述处理请求处理所述事件，所述事件具有事件标识；
用户标识查找模块402，配置为查找订阅所述第一用户标识的信息的第二用户标识；所述第二用户标识具有信息流列表；
信息流列表写模块403，配置为将所述事件标识写入所述信息流列表中；
事件信息发送模块404，配置为将所述信息流列表中事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
在本发明实施例的一种可选示例中，所述事件处理模块401还可以配置为：
将所述事件的事件信息存储到数据库中。
在本发明的一种可选实施例中，所述用户标识查找模块402还可以配置为：
生成事件任务；所述事件任务包括第一用户标识、事件标识；
将所述事件任务写入预置的任务队列中；
由预置的守护进程从所述任务队列中读取所述事件任务；
由预置的守护进程查找订阅所述第一用户标识的信息的第二用户标识。
在本发明的一种可选实施例中，所述事件任务还可以包括事件类型；所述用户标识查找模块402还可以配置为：
将所述事件任务写入与所述事件类型匹配的、预置的任务队列中。
在本发明的一种可选实施例中，所述用户标识查找模块402还可以配置为：
由预置的守护进程按照对所述事件类型设定的读取频率，从所述任务队列中按照先进先出的方式读取所述事件任务。
在具体实现中，所述事件类型可以具有优先级，第一事件类型的读取频率，高于，第二事件类型的读取频率；
其中，第一事件类型为优先级高于第二事件类型的事件类型；
第二事件类型为优先级低于第一事件类型的事件类型。
在本发明的一种可选实施例中，所述事件任务还可以包括事件类型；所述用户标识查找模块402还可以配置为：
当所述事件类型为发布型时，由所述守护进程查找订阅所述第一用户标识的信息的第二用户标识。
在本发明实施例的一种可选示例中，所述信息流列表写模块403还可以配置为：
由预置的守护进程将所述事件标识写入存储在Redis数据库中的信息流列表。
在本发明的一种可选实施例中，所述事件信息发送模块404还可以配置为：
当所述第二用户标识关联在线状态时，按照所述信息流列表中事件标识的时间顺序，将所述事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容， 并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当 理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的信息流数据的处理设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
例如，图5示出了用于执行根据本发明的信息流数据的处理方法的计算设备。该计算设备传统上包括处理器510和以存储器520形式的程序产品或者可读介质。存储器520可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM或者ROM之类的电子存储器。存储器520具有用于执行上述方法中的任何方法步骤的程序代码531的存储空间530。例如，用于程序代码的存储空间530可以包括分别用于实现上面的方法中的各种步骤的各个程序代码531。这些程序代码可以从一个或者多个程序产品中读出或者写入到这一个或者多个程序产品中。这些程序产品包括诸如存储卡之类的程序代码载体。这样的程序产品通常为如参考图6所述的便携式或者固定存储单元。该存储单元可以具有与图5的计算设备中的存储器520类似布置的存储段、存储空间等。程序代码可以例如以适当形式进行压缩。通常，存储单元包括可读代码531’，即可以由例如诸如510之类的处理器读取的代码，这些代码当由计算设备运行时，导致该计算设备执行上面所描述的方法中的各个步骤。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一 个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
本发明实施例公开了A1、一种信息流数据的处理方法，包括：
当接收到基于第一用户标识发起的一事件的处理请求时，按照所述处理请求处理所述事件，所述事件具有事件标识；
查找订阅所述第一用户标识的信息的第二用户标识；所述第二用户标识具有关联的信息流列表；
将所述事件标识写入所述信息流列表中；
将所述信息流列表中事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
A2、如A1所述的方法，所述按照所述处理请求处理所述事件的步骤包括：
将所述事件的事件信息存储到数据库中。
A3、如A1或A2所述的方法，所述查找订阅所述第一用户标识的信息的第二用户标识的步骤包括：
生成事件任务；所述事件任务包括第一用户标识、事件标识；
将所述事件任务写入预置的任务队列中；
由预置的守护进程从所述任务队列中读取所述事件任务；
由预置的守护进程查找订阅所述第一用户标识的信息的第二用户标识。
A4、如A3所述的方法，所述事件任务还包括事件类型；
所述将所述事件任务写入预置的任务队列中的步骤包括：
将所述事件任务写入与所述事件类型匹配的、预置的任务队列中。
A5、如A4所述的方法，所述由预置的守护进程从所述任务队列中读取所述事件任务的步骤包括：
由预置的守护进程按照对所述事件类型设定的读取频率，从所述任务队列中按照先进先出的方式读取所述事件任务。
A6、如A5所述的方法，所述事件类型具有优先级，第一事件类型的读取频率，高于，第二事件类型的读取频率；
其中，第一事件类型为优先级高于第二事件类型的事件类型；
第二事件类型为优先级低于第一事件类型的事件类型。
A7、如A3所述的方法，所述事件任务还包括事件类型；
所述由所述守护进程查找订阅所述第一用户标识的信息的第二用户标识的步骤包括：
当所述事件类型为发布型时，由所述守护进程查找订阅所述第一用户标识的信息的第二用户标识。
A8、如A1或A2或A4或A5或A6或A7所述的方法，所述将所述事件标识写入所述信息流列表中的步骤包括：
由预置的守护进程将所述事件标识写入存储在Redis数据库中的信息流列表。
A9、如A1或A2或A4或A5或A6或A7所述的方法，所述将所述信息流列表中事件标识对应的事件信息发送至所述第二用户标识对应的客户端的步骤包括：
当所述第二用户标识关联在线状态时，按照所述信息流列表中事件标识的时间顺序，将所述事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
本发明实施例还公开了B10、一种信息流数据的处理装置，包括：
事件处理模块，配置为在接收到基于第一用户标识发起的一事件的处理请求时，按照所述处理请求处理所述事件，所述事件具有事件标识；
用户标识查找模块，配置为查找订阅所述第一用户标识的信息的第二用户标识；所述第二用户标识具有信息流列表；
信息流列表写模块，配置为将所述事件标识写入所述信息流列表中；
事件信息发送模块，配置为将所述信息流列表中事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
B11、如B10所述的装置，所述事件处理模块还配置为：
将所述事件的事件信息存储到数据库中。
B12、如B10或B11所述的装置，所述用户标识查找模块还配置为：
生成事件任务；所述事件任务包括第一用户标识、事件标识；
将所述事件任务写入预置的任务队列中；
由预置的守护进程从所述任务队列中读取所述事件任务；
由预置的守护进程查找订阅所述第一用户标识的信息的第二用户标识。
B13、如B12所述的装置，所述事件任务还包括事件类型；所述用户标识查找模块还配置为：
将所述事件任务写入与所述事件类型匹配的、预置的任务队列中。
B14、如B13所述的装置，所述用户标识查找模块还配置为：
由预置的守护进程按照对所述事件类型设定的读取频率，从所述任务队列中按照先进先出的方式读取所述事件任务。
B15、如B14所述的装置，所述事件类型具有优先级，第一事件类型的读取频率，高于，第二事件类型的读取频率；
其中，第一事件类型为优先级高于第二事件类型的事件类型；
第二事件类型为优先级低于第一事件类型的事件类型。
B16、如B12所述的装置，所述事件任务还包括事件类型；所述用户标识查找模块还配置为：
当所述事件类型为发布型时，由所述守护进程查找订阅所述第一用户标识的信息的第二用户标识。
B7、如B10或B11或B13或B14或B15或B16所述的装置，所述信息流列表写模块还配置为：
由预置的守护进程将所述事件标识写入存储在Redis数据库中的信息流列表。
B18、如B10或B11或B13或B14或B15或B16所述的装置，所述事件信息发送模块还配置为：
当所述第二用户标识关联在线状态时，按照所述信息流列表中事件标识的时间顺序，将所述事件标识对应的事件信息发送至所述第二用户标识对应的客户端。

Claims (20)

  1. 一种信息流数据的处理方法，包括：
    当接收到基于第一用户标识发起的一事件的处理请求时，按照所述处理请求处理所述事件，所述事件具有事件标识；
    查找订阅所述第一用户标识的信息的第二用户标识；所述第二用户标识具有关联的信息流列表；
    将所述事件标识写入所述信息流列表中；
    将所述信息流列表中事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
  2. 如权利要求1所述的方法，其特征在于，所述按照所述处理请求处理所述事件的步骤包括：
    将所述事件的事件信息存储到数据库中。
  3. 如权利要求1或2所述的方法，其特征在于，所述查找订阅所述第一用户标识的信息的第二用户标识的步骤包括：
    生成事件任务；所述事件任务包括第一用户标识、事件标识；
    将所述事件任务写入预置的任务队列中；
    由预置的守护进程从所述任务队列中读取所述事件任务；
    由预置的守护进程查找订阅所述第一用户标识的信息的第二用户标识。
  4. 如权利要求3所述的方法，其特征在于，所述事件任务还包括事件类型；
    所述将所述事件任务写入预置的任务队列中的步骤包括：
    将所述事件任务写入与所述事件类型匹配的、预置的任务队列中。
  5. 如权利要求4所述的方法，其特征在于，所述由预置的守护进程从所述任务队列中读取所述事件任务的步骤包括：
    由预置的守护进程按照对所述事件类型设定的读取频率，从所述任务队列中按照先进先出的方式读取所述事件任务。
  6. 如权利要求5所述的方法，其特征在于，所述事件类型具有优先级，第一事件类型的读取频率，高于，第二事件类型的读取频率；
    其中，第一事件类型为优先级高于第二事件类型的事件类型；
    第二事件类型为优先级低于第一事件类型的事件类型。
  7. 如权利要求3所述的方法，其特征在于，所述事件任务还包括事件类型；
    所述由所述守护进程查找订阅所述第一用户标识的信息的第二用户标识的步骤包括：
    当所述事件类型为发布型时，由所述守护进程查找订阅所述第一用户标识的信息的第二用户标识。
  8. 如权利要求1或2或4或5或6或7所述的方法，其特征在于，所述将所述事件标识写入所述信息流列表中的步骤包括：
    由预置的守护进程将所述事件标识写入存储在Redis数据库中的信息流列表。
  9. 如权利要求1或2或4或5或6或7所述的方法，其特征在于，所述将所述信息流列表中事件标识对应的事件信息发送至所述第二用户标识对应的客户端的步骤包括：
    当所述第二用户标识关联在线状态时，按照所述信息流列表中事件标识的时间顺序，将所述事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
  10. 一种信息流数据的处理装置，包括：
    事件处理模块，配置为在接收到基于第一用户标识发起的一事件的处理请求时，按照所述处理请求处理所述事件，所述事件具有事件标识；
    用户标识查找模块，配置为查找订阅所述第一用户标识的信息的第二用户标识；所述第二用户标识具有信息流列表；
    信息流列表写模块，配置为将所述事件标识写入所述信息流列表中；
    事件信息发送模块，配置为将所述信息流列表中事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
  11. 如权利要求10所述的装置，其特征在于，所述事件处理模块还配置为：
    将所述事件的事件信息存储到数据库中。
  12. 如权利要求10或11所述的装置，其特征在于，所述用户标识查找模块还配置为：
    生成事件任务；所述事件任务包括第一用户标识、事件标识；
    将所述事件任务写入预置的任务队列中；
    由预置的守护进程从所述任务队列中读取所述事件任务；
    由预置的守护进程查找订阅所述第一用户标识的信息的第二用户标识。
  13. 如权利要求12所述的装置，其特征在于，所述事件任务还包括事件类型；所述用户标识查找模块还配置为：
    将所述事件任务写入与所述事件类型匹配的、预置的任务队列中。
  14. 如权利要求13所述的装置，其特征在于，所述用户标识查找模块还配置为：
    由预置的守护进程按照对所述事件类型设定的读取频率，从所述任务队列中按照先进先出的方式读取所述事件任务。
  15. 如权利要求14所述的装置，其特征在于，所述事件类型具有优先级，第一事件类型的读取频率，高于，第二事件类型的读取频率；
    其中，第一事件类型为优先级高于第二事件类型的事件类型；
    第二事件类型为优先级低于第一事件类型的事件类型。
  16. 如权利要求12所述的装置，其特征在于，所述事件任务还包括事件类型；所述用户标识查找模块还配置为：
    当所述事件类型为发布型时，由所述守护进程查找订阅所述第一用户标识的信息的第二用户标识。
  17. 如权利要求10或11或13或14或15或16所述的装置，其特征在于，所述信息流列表写模块还配置为：
    由预置的守护进程将所述事件标识写入存储在Redis数据库中的信息流列表。
  18. 如权利要求10或11或13或14或15或16所述的装置，其特征在于，所述事件信息发送模块还配置为：
    当所述第二用户标识关联在线状态时，按照所述信息流列表中事件标识的时间顺序，将所述事件标识对应的事件信息发送至所述第二用户标识对应的客户端。
  19. 一种程序，包括可读代码，当所述可读代码在计算设备上运行时，导致所述计算设备执行根据权利要求1至9中的任一项所述的信息流数据的处理方法。
  20. 一种可读介质，其中存储了如权利要求19所述的程序。
PCT/CN2016/086876 2015-06-26 2016-06-23 一种信息流数据的处理方法和装置 WO2016206600A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/739,881 US20180365254A1 (en) 2015-06-26 2016-06-23 Method and apparatus for processing information flow data

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510364378.4 2015-06-26
CN201510364378.4A CN105095365A (zh) 2015-06-26 2015-06-26 一种信息流数据的处理方法和装置

Publications (1)

Publication Number Publication Date
WO2016206600A1 true WO2016206600A1 (zh) 2016-12-29

Family

ID=54575802

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/086876 WO2016206600A1 (zh) 2015-06-26 2016-06-23 一种信息流数据的处理方法和装置

Country Status (3)

Country Link
US (1) US20180365254A1 (zh)
CN (1) CN105095365A (zh)
WO (1) WO2016206600A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019001349A1 (en) * 2017-06-29 2019-01-03 Beijing DIDI Infinity Technology and Development Co., Ltd SYSTEMS AND METHODS FOR TRANSMITTING FEEDSTREAM
WO2019048674A1 (en) 2017-09-11 2019-03-14 Pharmacosmos Holding A/S COMPLEX IRON COMPOUNDS FOR THERAPEUTIC USE
CN111385610A (zh) * 2020-03-17 2020-07-07 聚好看科技股份有限公司 控制广告时长的方法及装置
CN111522672A (zh) * 2020-04-24 2020-08-11 北京思特奇信息技术股份有限公司 一种用于熔断数据重复消费的方法及系统
CN112416627A (zh) * 2020-12-02 2021-02-26 北京皮尔布莱尼软件有限公司 一种基于流程的事件信息处理方法、计算设备及存储介质

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105095365A (zh) * 2015-06-26 2015-11-25 北京奇虎科技有限公司 一种信息流数据的处理方法和装置
CN107438061B (zh) * 2016-05-27 2020-03-03 北京京东尚科信息技术有限公司 一种kafka客户端鉴权的方法和装置
US11726842B2 (en) * 2016-08-02 2023-08-15 Salesforce, Inc. Techniques and architectures for non-blocking parallel batching
CN106487891B (zh) * 2016-10-11 2019-05-21 北京集奥聚合科技有限公司 一种基于kafka的处理消息的方法
CN108241616B (zh) * 2016-12-23 2023-07-25 阿里巴巴集团控股有限公司 消息推送方法和装置
CN111158936B (zh) * 2017-06-15 2024-04-09 北京忆芯科技有限公司 队列交换信息的方法及系统
CN107590005A (zh) * 2017-08-31 2018-01-16 武汉光谷信息技术股份有限公司 一种Redis内存队列中数据的获取方法及系统
CN107844325A (zh) * 2017-10-27 2018-03-27 上海斐讯数据通信技术有限公司 一种分布式数据的获取方法及系统
CN108023960B (zh) * 2017-12-08 2019-05-21 百度在线网络技术（北京）有限公司 构建Feed流应用的装置和Feed流信息推送的方法
CN108776840B (zh) * 2018-04-28 2024-04-02 拉卡拉支付股份有限公司 信息流推送方法、装置、电子设备及计算机可读存储介质
CN109218419A (zh) * 2018-09-05 2019-01-15 广东翼卡车联网服务有限公司 一种订阅推送的方法及平台
CN109710623A (zh) * 2018-12-10 2019-05-03 杭州爱聚科技有限公司 一种智能订单同步方法
CN109711122B (zh) * 2019-01-23 2021-04-30 北京奇艺世纪科技有限公司 一种权限管理方法、装置、系统、设备及可读存储介质
CN109800074A (zh) * 2019-02-21 2019-05-24 北京致远互联软件股份有限公司 任务数据并发执行方法、装置以及电子设备
CN110413427B (zh) * 2019-07-31 2022-03-22 中国工商银行股份有限公司 订阅数据拉取方法、装置、设备及存储介质
CN112380155A (zh) * 2019-09-25 2021-02-19 北京城建设计发展集团股份有限公司 基于云的轨道交通综合数据总线通信方法及系统
CN111259246A (zh) * 2020-01-17 2020-06-09 北京达佳互联信息技术有限公司 信息推送方法、装置、电子设备及存储介质
CN111935209A (zh) * 2020-06-28 2020-11-13 航天信息股份有限公司 一种基于用户状态对feed信息进行推送的方法及系统
CN112367540B (zh) * 2020-11-13 2022-09-20 广州易方信息科技股份有限公司 在线直播推流数监控的方法、装置
CN112527841A (zh) * 2020-12-17 2021-03-19 上海数依数据科技有限公司 一种流数据合并处理方法及装置
CN113379208B (zh) * 2021-05-28 2023-05-23 同盾科技有限公司 指标计算方法、装置及可读存储介质
CN113535361A (zh) * 2021-07-23 2021-10-22 百果园技术(新加坡)有限公司 任务调度方法、装置、设备及存储介质
CN113687932A (zh) * 2021-08-30 2021-11-23 上海商汤科技开发有限公司 一种任务调度的方法、装置、系统、电子设备及存储介质
CN114124881B (zh) * 2021-11-30 2023-06-20 中国建设银行股份有限公司 一种基于优先级的消息推送方法及相关装置
CN114489863A (zh) * 2022-02-16 2022-05-13 平安普惠企业管理有限公司 一种系统参数配置方法、装置、计算机设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101410802A (zh) * 2006-04-05 2009-04-15 松下电器产业株式会社 系统管理装置
CN101517554A (zh) * 2006-08-01 2009-08-26 摩托罗拉公司 多再现媒体事件切换
CN102214187A (zh) * 2010-04-12 2011-10-12 阿里巴巴集团控股有限公司 复合事件处理方法及装置
CN104281627A (zh) * 2013-07-12 2015-01-14 阿里巴巴集团控股有限公司 一种报告数据处理结果的方法、系统及事件追踪器
CN105095365A (zh) * 2015-06-26 2015-11-25 北京奇虎科技有限公司 一种信息流数据的处理方法和装置

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080126476A1 (en) * 2004-08-04 2008-05-29 Nicholas Frank C Method and System for the Creating, Managing, and Delivery of Enhanced Feed Formatted Content
GB0809875D0 (en) * 2008-05-30 2008-07-09 Vodafone Plc Communications management
US8635248B2 (en) * 2008-06-23 2014-01-21 Microsoft Corporation Providing localized individually customized updates from a social network site to a desktop application
CN101605301B (zh) * 2009-07-08 2012-09-26 中兴通讯股份有限公司 一种进行多节点事务处理的集群系统及请求消息分发方法
US8661076B2 (en) * 2010-09-23 2014-02-25 Salesforce.Com, Inc. Business networking information feed alerts
US20120101985A1 (en) * 2010-10-25 2012-04-26 Salesforce.Com, Inc. Triggering actions in an information feed system
US20120278329A1 (en) * 2011-04-29 2012-11-01 Google Inc. Tracking feeds in a social network
US20130061156A1 (en) * 2011-07-18 2013-03-07 Salesforce.Com, Inc. Computer implemented methods and apparatus for filtering information updates to display in a feed of an online social network
US9064287B2 (en) * 2011-10-13 2015-06-23 Salesforce.Com, Inc. Computer implemented methods and apparatus for providing group-related social network information
CN103177027B (zh) * 2011-12-23 2016-02-17 北京新媒传信科技有限公司 获取动态Feed索引的方法和系统
CN102902733B (zh) * 2012-09-11 2016-12-21 北京奇艺世纪科技有限公司 一种基于内容订阅的信息推送方法、装置及系统
CN103905521B (zh) * 2012-12-31 2018-05-18 中国移动通信集团公司 一种用于网络服务的信息处理系统和方法
US9823813B2 (en) * 2013-03-15 2017-11-21 Salesforce.Com, Inc. Apparatus and methods for performing an action on a database record
US10692096B2 (en) * 2013-03-15 2020-06-23 Thermodynamic Design, Llc Customizable data management system
US20140307735A1 (en) * 2013-04-11 2014-10-16 YakStack, LLC Model for managing the processes around the broadcasting of phone calls and text messages to groups of people
CN104281605B (zh) * 2013-07-08 2017-12-26 北京齐尔布莱特科技有限公司 一种社交网站Feed流推送方法
US11055340B2 (en) * 2013-10-03 2021-07-06 Minute Spoteam Ltd. System and method for creating synopsis for multimedia content
CN103618668A (zh) * 2013-12-18 2014-03-05 清华大学 微博推送、接收方法及装置
CN103927218B (zh) * 2014-04-30 2017-07-04 广州唯品会网络技术有限公司 事件分发方法及系统
CN105808618B (zh) * 2014-12-31 2019-10-22 阿里巴巴集团控股有限公司 Feed数据的存储和查询方法及其装置
CN104615716B (zh) * 2015-02-05 2017-12-01 北京航空航天大学 基于优先序列的分布式社交网络信息采集方法及系统
US9965541B2 (en) * 2015-02-24 2018-05-08 Salesforce.Com, Inc. Interest groups based on network feed items

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101410802A (zh) * 2006-04-05 2009-04-15 松下电器产业株式会社 系统管理装置
CN101517554A (zh) * 2006-08-01 2009-08-26 摩托罗拉公司 多再现媒体事件切换
CN102214187A (zh) * 2010-04-12 2011-10-12 阿里巴巴集团控股有限公司 复合事件处理方法及装置
CN104281627A (zh) * 2013-07-12 2015-01-14 阿里巴巴集团控股有限公司 一种报告数据处理结果的方法、系统及事件追踪器
CN105095365A (zh) * 2015-06-26 2015-11-25 北京奇虎科技有限公司 一种信息流数据的处理方法和装置

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019001349A1 (en) * 2017-06-29 2019-01-03 Beijing DIDI Infinity Technology and Development Co., Ltd SYSTEMS AND METHODS FOR TRANSMITTING FEEDSTREAM
WO2019048674A1 (en) 2017-09-11 2019-03-14 Pharmacosmos Holding A/S COMPLEX IRON COMPOUNDS FOR THERAPEUTIC USE
US11111261B2 (en) 2017-09-11 2021-09-07 Pharmacosmos Holding A/S Iron complex compounds for therapeutic use
CN111385610A (zh) * 2020-03-17 2020-07-07 聚好看科技股份有限公司 控制广告时长的方法及装置
CN111385610B (zh) * 2020-03-17 2021-12-24 聚好看科技股份有限公司 控制广告时长的方法及装置
CN111522672A (zh) * 2020-04-24 2020-08-11 北京思特奇信息技术股份有限公司 一种用于熔断数据重复消费的方法及系统
CN111522672B (zh) * 2020-04-24 2023-02-28 北京思特奇信息技术股份有限公司 一种用于熔断数据重复消费的方法及系统
CN112416627A (zh) * 2020-12-02 2021-02-26 北京皮尔布莱尼软件有限公司 一种基于流程的事件信息处理方法、计算设备及存储介质
CN112416627B (zh) * 2020-12-02 2023-08-18 北京皮尔布莱尼软件有限公司 一种基于流程的事件信息处理方法、计算设备及存储介质

Also Published As

Publication number Publication date
US20180365254A1 (en) 2018-12-20
CN105095365A (zh) 2015-11-25

Similar Documents

Publication Publication Date Title
WO2016206600A1 (zh) 一种信息流数据的处理方法和装置
US11288142B2 (en) Recovery strategy for a stream processing system
US10592282B2 (en) Providing strong ordering in multi-stage streaming processing
US11086687B2 (en) Managing resource allocation in a stream processing framework
CN109189835B (zh) 实时生成数据宽表的方法和装置
US10198298B2 (en) Handling multiple task sequences in a stream processing framework
US9842000B2 (en) Managing processing of long tail task sequences in a stream processing framework
CN107729139B (zh) 一种并发获取资源的方法和装置
US9712645B2 (en) Embedded event processing
US9805078B2 (en) Next generation near real-time indexing
US20170083368A1 (en) Maintaining throughput of a stream processing framework while increasing processing load
US10671589B2 (en) Synergizing real-time and polling connectors for data ingestion
US20180329860A1 (en) Remote direct memory access (rdma) high performance producer-consumer message processing
WO2015051690A1 (zh) 一种基于zookeeper的信息配置方法及装置
US8725684B1 (en) Synchronizing data stores
US9038093B1 (en) Retrieving service request messages from a message queue maintained by a messaging middleware tool based on the origination time of the service request message
CN111177237B (zh) 一种数据处理系统、方法及装置
US9760576B1 (en) System and method for performing object-modifying commands in an unstructured storage service
US8510426B2 (en) Communication and coordination between web services in a cloud-based computing environment
US9473561B2 (en) Data transmission for transaction processing in a networked environment
Hurst et al. Social streams blog crawler
CN113127225A (zh) 一种数据处理任务的调度方法、装置和系统
CN114168607A (zh) 全局序列号生成方法、装置、设备、介质和产品
US8473419B1 (en) Dependency resolution in publish/subscribe
US9430514B1 (en) Locking metadata associated with catalog items

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16813716

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16813716

Country of ref document: EP

Kind code of ref document: A1