一种数据处理方法、装置、设备及存储介质与流程

1.本技术涉及数据处理技术领域，涉及但不限于一种数据处理方法、装置、设备及存储介质。


背景技术：

2.随着互联网技术的发展，智慧医疗得到广泛应用，各种智慧医疗应用程序(application，app)逐渐进入人们的生活。对于智慧医疗app，需要处理的数据量十分庞大，对时效性与可用性要求较高。
3.相关技术中，对庞大的数据进行处理过程可以包括：第一种方案是将数据统一存储于一个数据库，进行数据处理时，从数据库中采用遍历的方式调用目标数据，并对目标数据进行相关处理；第二种方案是将数据通过一个中间件存储于缓存，进行数据处理时，通过该中间件采用遍历的方式从缓存调用目标数据，并对目标数据进行相关处理。
4.对于上述两种方案，在进行数据处理时，均需在庞大的存储空间中通过遍历的方式查找目标数据，这样，响应时间较长，数据处理效率较低，无法满足数据处理的时效性的要求。


技术实现要素：

5.本技术提供一种数据处理方法及装置、设备、存储介质，能够减少数据处理的响应时间，提高数据处理效率，满足数据处理的时效性的要求。
6.本技术的技术方案是这样实现的：
7.本技术提供了一种数据处理方法，所述方法包括：
8.接收第一请求，并且确定所述第一请求请求处理的目标数据的数据类型；
9.基于所述目标数据的数据类型从缓存包括的至少一个区域中，确定目标区域；所述至少一个区域中，不同区域用于存储不同数据类型的数据；
10.在所述目标区域中对所述目标数据，执行所述第一请求对应的处理。
11.本技术提供了一种数据处理装置，所述装置包括：
12.接收单元，用于接收第一请求，并且确定所述第一请求请求处理的目标数据的数据类型；
13.确定单元，用于基于所述目标数据的数据类型从缓存包括的至少一个区域中，确定目标区域；所述至少一个区域中，不同区域用于存储不同数据类型的数据；
14.处理单元，用于在所述目标区域中对所述目标数据，执行所述第一请求对应的处理。
15.本技术还提供了一种电子设备，包括：存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述数据处理方法。
16.本技术还提供了一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述数据处理方法。
17.本技术所提供的数据处理方法、装置、设备及存储介质，包括：接收第一请求，并且确定所述第一请求请求处理的目标数据的数据类型；基于所述目标数据的数据类型从缓存包括的至少一个区域中，确定目标区域；所述至少一个区域中，不同区域用于存储不同数据类型的数据；在所述目标区域中对所述目标数据，执行所述第一请求对应的处理。本技术提供的一种数据处理方案，由于将具有不同数据类型的数据存储于缓存中的不同区域，这样，在进行数据处理时，先基于请求确定目标数据的数据类型，再基于数据类型确定目标区域，然后在目标区域中对目标数据进行数据处理，从而能够减少数据处理的响应时间，提高数据处理效率，满足数据处理的时效性的要求。
附图说明
18.图1为本技术实施例提供的数据处理系统的一种可选的结构示意图；
19.图2为本技术实施例提供的数据处理方法的一种可选的流程示意图；
20.图3为本技术实施例提供的数据处理方法的一种可选的流程示意图；
21.图4为本技术实施例提供的数据处理方法的一种可选的流程示意图；
22.图5为本技术实施例提供的数据处理系统的一种可选的结构示意图；
23.图6为本技术实施例提供的数据同步过程的一种可选的结构示意图；
24.图7为相关技术提供的订单推送方法的一种可选的结构示意图；
25.图8为本技术实施例提供的前置计算过程的一种可选的结构示意图；
26.图9为本技术实施例提供的处方系统和订单缓存的一种可选的结构示意图；
27.图10为本技术实施例提供的处方系统和订单缓存的一种可选的结构示意图；
28.图11为本技术实施例提供的内容区域、关系区域的一种可选的结构示意图；
29.图12为本技术实施例提供的数据处理装置的一种可选的结构示意图；
30.图13为本技术实施例提供的电子设备的一种可选的结构示意图。
具体实施方式
31.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对申请的具体技术方案做进一步详细描述。以下实施例用于说明本技术，但不用来限制本技术的范围。
32.在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
33.在以下的描述中，所涉及的术语“第一\第二\第三”仅是为例区别不同的对象，不代表针对对象的特定排序，不具有先后顺序的限定。可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本技术实施例能够以除了在这里图示或描述的以外的顺序实施。
34.除非另有定义，本文所使用的所有的技术和科学术语与属于本技术的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本技术实施例的目的，不是旨在限制本技术。
35.本技术实施例可提供数据处理方法及装置、设备和存储介质。实际应用中，数据处
理方法可由数据处理装置实现，数据处理装置中的各功能实体可以由电子设备(如终端设备)的硬件资源，如处理器等计算资源、通信资源(如用于支持实现光缆、蜂窝等各种方式通信)协同实现。
36.本技术实施例提供的数据处理方法应用于数据处理系统，数据处理系统包括数据处理端。
37.数据处理端接收第一请求，并且确定所述第一请求请求处理的目标数据的数据类型；基于所述目标数据的数据类型从缓存包括的至少一个区域中，确定目标区域；所述至少一个区域中，不同区域用于存储不同数据类型的数据；在所述目标区域中对所述目标数据，执行所述第一请求对应的处理。
38.数据处理系统还可以包括客户端。
39.作为一示例，数据处理系统的结构可如图1所示，包括：客户端10和数据处理端20。
40.在一示例中，客户端10和数据处理端20可为同一物理实体；在一示例中，如图1所示，客户端10和数据处理端20可为不同的物理实体，且客户端10和数据处理端20之间通过网络30进行交互。
41.这里，客户端10用于接收用户的操作，基于用户的操作，向数据处理端20发送第一请求。数据处理端20接收客户端10发送的第一请求。
42.下面，结合图1所示的数据处理装置的示意图，对本技术实施例提供的数据处理方法及装置、设备和存储介质的各实施例进行说明。
43.本技术实施例提供一种数据处理方法，该方法应用于数据处理装置，其中，数据处理装置可部署于作为数据处理端的电子设备上。
44.图2示意了一种可选的一种数据处理方法的流程示意图，本技术实施例提供的数据处理方法，用于对数据进行处理，现以目标数据为例，对目标数据的数据过程进行详细说明。
45.该数据处理方法可以包括但不限于图2所示的下述s201至s203。
46.s201、电子设备接收第一请求，并且确定所述第一请求请求处理的目标数据的数据类型。
47.本技术实施例对第一请求的操作类型不作限定，可以根据实际需求进行配置。第一请求的操作类型可以包括但不限于下述至少一项：读取请求、写入请求、查询请求、删除请求、修改请求以及更新请求。
48.在一种可能的实施方式中，电子设备接收用户的第一操作，并基于该第一操作接收第一请求，并确定第一请求请求处理的目标数据的数据类型。
49.在另一种可能的实施方式中，客户端接收用户的第一操作，并基于该第一操作接收第一请求，客户端将接收的第一请求发送至电子设备，电子设备接收客户端发送的第一请求，并确定第一请求请求处理的目标数据的数据类型。
50.需要说明的是，客户端将接收的第一请求发送至电子设备可以包括：客户端将接收的第一请求直接发送至电子设备，即第一消息的发送不经过除电子设备和客户端之外的设备；或者，客户端将接收的第一请求发送至第一设备(除电子设备和客户端之外的设备)，第一设备将第一请求转发至电子设备。
51.本技术实施例对数据类型不作具体限定，可以根据实际需求进行配置。例如，数据
类型可以包括以下至少一种：订单数据、静态数据、状态数据和计数数据。
52.例如，电子设备在接收的第一请求为“读取今日订单数量”的情况下，确定目标数据的为计数数据。
53.s202、电子设备基于所述目标数据的数据类型从缓存包括的至少一个区域中，确定目标区域。
54.至少一个区域中，不同区域用于存储不同数据类型的数据。
55.本技术实施例对缓存包括的区域的数量，以及不同区域所存储的不同类型的数据不作限定，可以根据实际需求进行配置。
56.示例a1，缓存可以包括4个区域，分别为第一区域、第二区域、第三区域、第四区域，其中，第一区域用于存储订单数据，第二区域用于存储静态数据，第三区域用于存储状态数据，第四区域用于存储计数数据。
57.示例a2，缓存可以包括6个区域，分别为第一区域、第二区域、第三区域、第四区域、第五区域、第六区域，其中，第一区域用于存储接收到的订单数据，第二区域用于存储用户(例如医生)输出的订单数据，第三区域用于存储段落性的静态数据，第四区域用于存储名词性的静态数据，第五区域用于存储状态数据，第六区域用于存储计数数据。
58.s202可以实施为：电子设备基于目标数据的数据类型，从缓存包括的至少一个区域中，确定存储目标数据的区域，作为目标区域。
59.针对示例a1，s202可以为示例b1：若电子设备确定目标数据的数据类型为订单数据类型，则确定目标区域为第一区域；若电子设备确定目标数据的数据类型为静态数据类型，则确定目标区域为第二区域；若电子设备确定目标数据的数据类型为状态数据类型，则确定目标区域为第三区域；若电子设备确定目标数据的数据类型为计数数据类型，则确定目标区域为第四区域。
60.s203、电子设备在所述目标区域中对所述目标数据，执行所述第一请求对应的处理。
61.电子设备在目标区域中对目标数据，执行第一请求对应的处理。
62.在一种可能的实施方式中，第一请求为读取请求，电子设备在目标区域中读取目标数据。
63.在一种可能的实施方式中，第一请求为写入请求，电子设备将目标数据写入目标区域。
64.本技术实施例对目标数据的写入顺序不作限定，可以根据实际需求进行配置。例如，电子设备可以按照写入时间的先后顺序将目标数据写入；或者，电子设备可以按照预设的顺序(例如，订单成交时间先后顺序，预设的科室顺序等等)将目标数据写入。
65.本技术实施例提供的数据处理方法包括：接收第一请求，并且确定所述第一请求请求处理的目标数据的数据类型；基于所述目标数据的数据类型从缓存包括的至少一个区域中，确定目标区域；所述至少一个区域中，不同区域用于存储不同数据类型的数据；在所述目标区域中对所述目标数据，执行所述第一请求对应的处理。本技术提供的数据处理方法，由于将具有不同数据类型的数据存储于缓存中的不同区域，这样，在进行数据处理时，先基于请求确定目标数据的数据类型，再基于数据类型确定目标区域，然后在目标区域中对目标数据进行数据处理，从而能够减少数据处理的响应时间，提高数据处理效率，满足数
据处理的时效性的要求。
66.下面对s201和s203的执行进行简单说明，可以包括但不限于下述方式1或方式2。
67.方式1、通过同一任务执行s201和s203；
68.方式2、通过不同任务执行s201和s203。
69.方式1：电子设备通过第一任务接收第一请求，并且确定所述第一请求请求处理的目标数据的数据类型；电子设备通过第一任务在目标区域中对目标数据，执行第一请求对应的处理。
70.方式1可以通过一个任务实现接收第一请求的动作与处理第一请求的动作，实现简单，能够进一步减少数据处理的响应时间。
71.方式2：电子设备通过第一任务接收第一请求；电子设备通过第二任务在目标区域中对目标数据，执行第一请求对应的处理。
72.第一任务与第二任务不同。本技术实施例对第一任务和第二任务的任务类型和执行时机不作限定，可以根据实际需求进行配置。例如，对于任务类型而言，第一任务可以是前台任务，第二任务可以是后台任务；对于执行实际而言，第一任务可以是实时处理任务，第二任务可以是实时处理任务或者空闲处理任务。
73.方式2可以通过第一任务实现接收第一请求，并且确定所述第一请求请求处理的目标数据的数据类型的动作，通过第二任务与处理第一请求的动作；这样可以根据实际需求配置第一任务和第二任务，灵活性高。且在第一任务是前台任务，第二任务是后台任务的情况下，用户对第一请求的处理过程不感知，可以提高用户体验。
74.需要说明的是，本技术实施例对执行s202的任务不作限定，可以根据实际需求进行配置。例如，执行s202的任务可以与执行s201的任务相同；或者也可以与执行s203的任务相同；或者也可以通过不同于第一任务和第二任务的第三任务执行s202。
75.下面，对s203电子设备在所述目标区域中对所述目标数据，执行所述第一请求对应的处理的过程进行说明，具体可以包括但不限于下述方式a1至a4中任一方式：
76.目标区域为第一区域场景下的方式a1，第一区域用于存储订单数据；
77.目标区域为第二区域场景下的方式a2，第二区域用于存储静态数据；
78.目标区域为第三区域场景下的方式a3，第三区域用于存储状态数据；
79.目标区域为第四区域场景下的方式a4，第四区域用于存储计数数据。
80.下面，对方式a1，目标区域为第一区域，电子设备在目标区域中对目标数据，执行第一请求对应的处理的实施过程进行说明。
81.方式a1可以包括但不限于图3所示的s301和s302。
82.s301、电子设备在所述第一区域中确定第一目标子区域。
83.第一区域中的不同子区域用于存储不同用户的订单数据，示例性的，第一区域中的不同子区域用于存储不同医生的订单数据。订单数据可以包括：接收的订单和输出的订单。
84.在一种可能的实施方式中，在第一请求为写入请求的情况下，电子设备根据预设规则，在第一区域中确定第一目标子区域。
85.预设规则用于根据在第一区域中确定第一目标子区域，本技术实施例对预设规则的具体内容不作限定，可以根据实际需求进行配置。
86.预设规则可以包括：按照接收请求的时间确定第一目标子区域。
87.例如，若第一请求用于请求写入订单1，第一请求的接收时间为10：00，则将第一目标子区域为存储医生a的订单数据的子区域。也可以理解为，将第一请求分配给医生a处理。
88.预设规则还可以包括：基于用户针对第一请求的第二操作，确定第一目标子区域。
89.例如，若第一请求用于请求写入订单2，用户b(医生b)针对第一请求进行了第二操作(也可以称为抢单操作)，电子设备基于该第二操作确定第一目标子区域为存储用户b的订单数据的子区域。也可以理解为，将第一请求分配给医生b处理。
90.在一种可能的实施方式中，在第一请求为读取请求的情况下，电子设备将第一区域中与第一请求存在关联关系的子区域确定为第一目标子区域。
91.例如，在第一请求为读取订单3，其中，第一请求的订单3与存储用户c的订单数据的子区域存储关联关系(订单3属于医生c处理)，则电子设备将存储用户c的订单数据的子区域确定为第一目标子区域。
92.s302、电子设备在所述第一目标子区域中对所述目标数据，执行所述第一请求对应的处理。
93.在一种可能的实施方式中，第一请求为读取请求，电子设备在第一目标子区域中读取目标数据。
94.在一种可能的实施方式中，第一请求为写入请求，电子设备将目标数据写入第一目标子区域。
95.下面，对方式a2针对目标区域为第二区域，电子设备在目标区域中对目标数据，执行第一请求对应的处理的实施过程的实施过程进行说明。方式a2可以包括但不限于图4所示的s401至s403。
96.s401、电子设备确定所述目标数据的访问状态。
97.电子设备判断目标数据的访问频率是否大于或等于第一频率阈值，若目标数据的访问频率大于或等于第一频率阈值，则确定目标数据的访问状态为第一状态；若目标数据的访问频率小于第一频率阈值，则确定目标数据的访问状态为第二状态。
98.s402、电子设备基于所述访问状态，在所述第二区域中确定第二目标子区域。
99.第二区域中的不同子区域用于存储不同访问状态的静态数据。
100.电子设备在第二区域中，确定存储该目标数据的访问状态数据的子区域为第二目标子区域。
101.s403、电子设备在所述第二目标子区域中对所述目标数据，执行所述第一请求对应的处理。
102.在一种可能的实施方式中，第一请求为读取请求，电子设备在第二目标子区域中读取目标数据。
103.在一种可能的实施方式中，第一请求为写入请求，电子设备将目标数据写入第二目标子区域。
104.下面，对s402电子设备基于访问状态，在第二区域中确定第二目标子区域，的过程进行说明，可以包括但不限于下述实施方式a或实施方式b。
105.实施方式a、针对第一状态，确定第一子区域为第二目标子区域；
106.实施方式b、针对第二状态，确定第二子区域为第二目标子区域。
107.实施方式a：若目标数据的访问状态为表征热点数据的第一状态，电子设备确定第一子区域为第二目标子区域，其中，第一子区域通过第一中间件缓存数据。
108.实施方式b：若目标数据的访问状态为表征为非热点数据的第二状态，电子设备确定第二子区域为第二目标子区域，其中，第二子区域通过第二中间件缓存数据。
109.第二中间件的数据处理速率小于第一中间件的数据处理速率。本技术实施例对第一中间件和第二中间件的具体类型不作限定，可以根据实际需求进行配置。例如，第一中间件可以为分布式的高速缓存(memcached)；第二中间件可以为远程字典服务(remote dictionary server，redis)。
110.下面，对方式a3针对目标区域为第三区域，电子设备在目标区域中对目标数据，执行第一请求对应的处理的实施过程进行说明。
111.第三区域用于存储状态数据，其中，状态数据指用于表征状态的数据，本技术实施例对状态数据不作具体限定，可以根据实际需求进行配置，例如，状态数据可以包括：消息是否被读取，处方是否提交等。
112.方式a3：通过布隆过滤器在所述第三区域中对所述目标数据，执行所述第一请求对应的处理。
113.在一种可能的实施方式中，第一请求为写入请求，电子设备通过布隆过滤器确定该写入请求在第三区域中对应的映射位置，电子设备将目标数据转换为第一数值后，将第一数值写入该映射区域。其中，该第一数值用于表征该目标数据。
114.在一种可能的实施方式中，第一请求为读取请求，电子设备通过布隆过滤器确定该读取请求在第三区域中对应的映射位置，读取该映射位置的取值，得到目标数据。
115.通过方式3在目标区域中对目标数据，执行第一请求对应的处理，由于缓存状态数据时，不是将状态数据直接缓存，而是通过布隆过滤器得到状态数据在第三区域的映射位置，将状态数据转换为第一数值(表征第一状态)或者第二数值(表征第二状态)，存储在映射位置。这样，一方面降低了存储量，提高了存储效率；另一方面，提高了读取效率。
116.下面，对方式a4针对目标区域为第四区域，电子设备在目标区域中对目标数据，执行第一请求对应的处理的实施过程进行说明。
117.第四区域用于存储计数数据，其中，计数数据指可以计数的数据，本技术实施例对计数数据不作具体限定，可以根据实际需求进行配置。例如，计数数据可以包括：历史订单数量、今日订单数量、历史患者数量、科室数量以及医生数量等等。
118.第四区域为缓存区域，本技术实施例对第四区域的缓存类型不作具体限定，可以根据实际需求进行配置。例如，第四区域可以为高速缓冲存储器(cache)。
119.在一种可能的实施方式中，第一请求为写入请求，电子设备确定目标数据大于或等于1，在第四区域中写入目标数据。
120.需要说明的是，若目标数据等于0，则对目标数据不做存储，换而言之，对于计数次数为0的计数数据不做存储。
121.在一种可能的实施方式中，第一请求为读取请求，电子设备在第四区域读取目标数据。
122.需要说明的是，若遍历第四区域所有的对象，没有查找到目标数据，则确定目标数据对应的计数为0。
123.通过方式4在目标区域中对目标数据，执行第一请求对应的处理，一方面，计数数据存储于缓存中，数据处理的响应时间较短，另一方面，对于第四区域只存储计数大于或等于1的数据，对于计数等于0的数据不做存储，提高了缓存空间的利用率。
124.下面，通过具体的应用场景对本技术实施例提供的数据处理方法进行说明。
125.在互联网医院的医生app中，最为重要的功能之一就是订单列表服务，该服务是医生每天使用占比最高的功能之一，具有并发量高(访问量较大)、功能逻辑复杂，实效性要求高、可用性要求高、容错率低的特点，由于订单列表服务具备的以上特点，因此，设计一个高可用、易扩展、高性能的订单列表服务就显得尤为重要。
126.下面，对上述特点进行介绍：
127.1、访问量较大：医生app在线注册医生10万，日活医生达到2万，每个医生都需要使用订单列表服对患者提供问诊服务，平时的每分钟请求量(query/min，q/m)达到了1万，而到了618、双11期间，则直接飙升至10万q/m，是平时10倍量。
128.2、功能逻辑复杂：订单列表服务是医生使用的高频功能，该服务集成了丰富的业务功能，医生能看到患者定向给该医生的订单(定向单)，也可以看到系统通过病情描述、患者信息指派给该医生的订单(派单)，同样医生也可以抢他认为他可以诊治的订单(抢单)，最终系统架构演变的计算、存储、同步、缓存等功能也极度复杂。
129.静态信息类(相当于静态数据)：订单类型、疾病主诉、患者上传的疾病图片、患者信息(年龄、性别、姓名等)。
130.动态计算类：医患会话最后一句话内容、订单结束倒计时、是否有未读消息需要小红点提醒、问诊按钮可以出现哪些(拒诊、接诊、转诊、退诊、结诊)等。
131.是否存在类(相当于状态数据)：该订单是否被主责医生回复、是否被转诊、是否属于vip、是否已经开具处方、是否能已经延诊等。
132.计数类(相当于计数数据)：订单被专家团队中几个人回复过，该患者历史问诊次数等。
133.排序规则：根据下单时间排序、根据患者回复最后一句话的时间排序、根据订单金额大小排序等。
134.3、实效性要求高：由于医疗行业的特殊性，问诊看病一定是“着急的事”，因而订单列表服务对实效性要求很高，例如开具处方后，处方信息要能够在专家团队群里边实时的同步到所有人，且让一部分医生不能再重复开方；订单时间到期后，订单状态自动刷新；医生使用该服务必须保证功能流畅，数据的获取必须要在5ms以内，响应时间必须在10-40ms以内。
135.4、可用性要求高：在线医疗的核心功能就是医患通过网络以文字、图片、语音、视频等方式交流，而订单列表又是医生管理患者的并提供服务的重中之重，如果该服务不可用，则医患无法沟通，整个互联网医院彻底瘫痪，因而，可用性必须在99.99％以上。
136.5、容错率低：该服务如果出现丢单、消息不及时、订单提前结束、会话排序错乱、红点提示不及时等问题，则会造成医生使用上的困扰，并最终影响患者的问诊效果、康复进度等一系列问题，因而该服务容错率很低，对架构的设计提出了很高的要求。
137.相关技术中，针对订单列表服务中数据的处理过程包括下述技术1或技术2：
138.技术1同步调用：通过数据库(data base，db)进行检索相关订单，每次都在线同步
调用、临时计算相关数据。技术1使用数据库db来作为存储介质，由于大部分数据库都是采用机械磁盘，其性能不如缓存高效，在大流量高并发场景下无法应对如此之高的压力，尤其是大促期间极其可能将数据库打挂，出现严重线上事故。
139.技术2单一缓存：利用redis中间件的高性能，将数据缓存在redis单一中间件，每次从redis获取数据并组装最终的结果给前端应答。技术2只使用单一redis缓存中间件，相比第一种技术方案解决了大部分的性能问题，但是由于redis数据容量(单实例)是在30gb以内，且内容利用率不高，很难覆盖所有场景，且造成的服务器数量浪费情况严重。
140.本技术提供了一种数据处理方法，能够为用户提供高可用、高性能的订单列表服务，功能逻辑正确、响应快速的数据处理方案。
141.首先，对多种缓存中间件进行简单说明，表1为缓存中间件对比示例。
142.表1缓存中间件对比示例
[0143][0144]
其中，通过表1的中对各缓存中间件的对比，可以灵活对各种数据类型的数据配置适合的中间件进行缓存数据，从而提高处理处理效率。
[0145]
对本技术实施例涉及的部分技术术语做简单说明。
[0146]
前置计算：提前将数据存储好。
[0147]
消息队列(message queue，mq)：内部的消息组件，可以提供主题维度生产、消费的功能。
[0148]
远程字典服务(remote dictionary server，redis)：一种支持多种方式的内存级别的存储中间件，其可以提供内存级别的性能。
[0149]
异构缓存：将数据以不同的格式备份。
[0150]
上述各类手段均很难全方位的解决问题，因而本方案提出了一种借助多套、多级也就是多维度缓存模型方案，该方案具有以下几个特点：前置计算、异步处理，异构缓存、高效应答，统一平台、数据可视。
[0151]
本技术实施例提供的数据处理方法，应用于数据处理系统，图5示意了一种数据处理系统的结构。
[0152]
如图5所示，处理处理系统包括：客户端设备501、缓存网关502、配置设备503、缓存代理设备504、更新服务策略设备505以及存储设备506(相当于上述电子设备或者上述数据处理端)。
[0153]
客户端设备501，用于基于客户的操作接收第一请求，并将第一请求发送至缓存网关502。
[0154]
缓存网关502，用于接收第一请求，并根据用户位置将第一请求分发到距离用户位置最近的网关服务器上。其中，而在网关服务器上安装反向代理服务器(nginx)，其利用多路复用并发机制(epoll)模型，可以轻松解决单台服务器只能处理1万个链接的上限问题(c10k问题)，并且nginx结合lua语言脚本，针对用户个人识别码(personal identification number，pin)进行识别，拦截同一个pin在短时间内的重复请求。
[0155]
配置中设备503，本技术设计的是多维度冗余存储，因为由于用户量较大，不同的用户分别访问不同的缓存，可以进行分流操作，从而减少后台服务器的压力。在使用的时候，针对不同用户会注册不同的命名空间(namespace)，并且根据命名空间去找对应的缓存中间件。从而实现通过后台缓存上下架、更换网际互连协议(internet protocol，ip)，前端不感知具体的服务器变化。
[0156]
缓存代理设备504，用于屏蔽不同缓存的协议之间的差异。因为本技术汇集了多类缓存中间件，缓存代理设备504的作用之一就是能够屏蔽各种缓缓存中间件的协议差异。另外一个作用就是读写分离，即读取操作均访问存储设备506，而写操作则会被分流到更新服务策略设备505，其中，更新服务策略设备505支持缓存更新策略服务(update-server，us)。
[0157]
更新服务策略设备505，用于让一个数据高效的同步给多套服务器，从而全面的提升用户的体验度。如图6所示，数据同步可以包括：缓存代理设备504先分析请求指令是读取还是写入，如果是读取请求则直接读取本地缓存即可，而如果是写入请求，则首先路由到更新服务策略设备505，更新服务策略设备505首先更新本地资源，成功后再路由到主机房的存储设备506。主机房存储设备506的接收写入请求，并逐级同步到其他从机房的存储设备506，从而实现数据同步。
[0158]
存储设备506，可以包括接收队列区域5061、输出队列区域5062、内容区域5063、关系区域5064、状态区域5065、计数区域5066。其中，接收队列区域5061和输出队列区域5062相当于上述第一区域，内容区域5063和关系区域5064相当于上述第二区域，状态区域5065相当于上述第三区域，计数区域5066相当于上述第四区域。
[0159]
接收队列区域5061、输出队列区域5062：
[0160]
相关技术中，通常采用推送的方式，如图7所示，患者下了一个骨科订单1，将这个骨科订单1推送给所有骨科医生(骨科医生1、骨科医生2等等)名下，架构简单便于理解，但是缺点是在高流量下性能相对低下。
[0161]
医生在线注册医生10万，骨科、男科、内科均是大科，这些科室的注册医生均在1-2万，因而一个患者下一个订单就向1万名医生名下投递，对服务器的性能压力过大，这种方式是不可取的，基于以上原因本方案设计了一种推拉集合(hybrid)的方式，可以包括前置计算、数据聚合、事件驱动和离线处理。
[0162]
前置计算
[0163]
当某位医生(医生d)访问请求时，会从医生d的队列(图8中医生d订单列表)中获取数据，而医生d的队列中的数据是经过前置计算、存储好的，并不是在接收到医生的访问请求后才进行计算，这样加快了响应速度，能够达到40毫秒(millisecond，ms)内应答。
[0164]
数据聚合
[0165]
一个医生的存储数据来源可以包括下述一项或者多项：
[0166]
1)不同患者下的订单；
[0167]
订单与医生相关时，医生就可以接该订单，通过事件驱动将不同患者的输出队列中订单分配给对应的医生的订单列表中。
[0168]
2)群聊中的订单；
[0169]
群聊一般包括主责管家、专家团队等这两类，同一个团队中的医生均可以获取到群聊中的订单。
[0170]
3)抢单；
[0171]
抢单是医生根据自己的意愿进行抢单，这类订单抢到之后就属于该医生。
[0172]
4)定向单；
[0173]
这类订单是患者指定给某位医生下的订单，一般多为三甲医院名医，这类订单也会被率先放到某位医生名下。
[0174]
5)消息；
[0175]
消息主要是包括医患对话，通常是最后一句话的文案和时间戳等。
[0176]
6)处方信息。
[0177]
处方信息包括开方的诊断、药品信息、处方状态等信息。
[0178]
如图8所示，1)(患者下的订单)是输出队列，2)到6)(群聊中的订单、抢单、定向单、消息以及处方信息)均为输入队列，不同的数据放入不同的队列，最终系统进行数据聚合，并缓存与不同医生的队列存储区域(例如医生d订单列表)。
[0179]
事件驱动
[0180]
消息由发送消息事件进行驱动。例如，订单分为定向单和非定向单，定向单通过订单系统打入对应的数据队列，而非定向单则通过分诊系统打入数据队列，消息系统会将医患的每一句对话发送事件，不断覆盖数据队列末端数据，处方系统在处方开具、提交、审核、驳回、通过、购药等多个维度均会发送消息事件。消息事件避免了不停轮询产生的不必要的性能消耗，且更为及时。
[0181]
离线处理
[0182]
在处理订单数据时均采用离线处理的方式，而不是常规的同步处理，因为同步处理对性能的压力巨大，离线处理可以有效避免该压力，但是由此带来的问题就是如果出现消息积压则会造成数据的不及时，患者发生的动作，而医生端不能及时发现，因而在处理这样的情况时会采用半同步 消息队列(message queue，mq)补偿的方式：
[0183]
如图9所示，以处方系统和订单缓存两者之间的关系为例，如果处方系统同步添加数据到订单缓存侧，则会严重影响处方系统，因而首选mq消息事件离线处理，但是如果出现mq积压，则会影响整个系统，因而在mq消息事件之外再添加一层半同步，也就是提交一个异步任务放到线程池，该任务就是同步数据到订单缓存，但是由于该线程池也会出现积压等
情况，但是相比mq整体的积压已经风险小了很多，因而目前都是采用分布式服务，一台服务有问题，别的服务器不一定有问题，这样做到了风险隔离。
[0184]
内容区域5063、关系区域5064：
[0185]
在订单列表服务中需要显示患者的姓名、性别、身高、体重、过往病例等信息，整个互联网医院共计有6000多万患者信息；还需要医生的姓名、科室、年龄等信息，目前共有10万医生，这些静态数据中有大量的热点型数据，例如某位名医，该医生每天接单量就过千；此外还有团队成员和团队领队等信息，。综上有大量的基础数据和大量的热点数据，必须要将数据进行缓存，并且缓存之后数据还可以复用提供给医生主页、搜索、评价等多个功能，降低存储成本，具体而言，本技术实施例对存储静态数据的内容区域5063、关系区域5064采用了4层架构，如图10所示，l1层(相当于第二区域的第一子区域)用于存储热点型数据，l2层(相当于第二区域的第二子区域)用于存储非热点型数据，l3层用于备份非热点型数据，l4层用于备份所有静态数据。
[0186]
l1层用于存储热点型数据，热点型数据可以包括热门医生、热门医院、热门科室、热门团队、高价订单、当前某科室可抢订单数量等数据，热点型数据的特点是存储量小、响应速度快，首先是存储量小，且是一小块一小块的存储的，块和块之间隔离开，可以防止突然间的流量冲击，导致大面积的功能失效，能够有效的隔离风险；其次就是响应速度要快，所以l1层采用memcached中间件进行缓存，处理速度较快。
[0187]
需要说明的是，l1层存储的热点型数据是动态更新的。例如某些数据不再热门是，则会降级存储到l2层，也就是说不再是热点数据。
[0188]
l2层和l3层之间是互相备份的关系，存储了非热点型的静态数据。
[0189]
l2层和l3层存储的非热点型数据也是动态更新的，例如当数据1某次访问频率大于或等于第一频率阈值是，则会将数据1首先从l2和l3层中删除，同时将数据1作为热点型数据存储于l1层。
[0190]
l4层则是db层，用于备份所有静态数据。
[0191]
经过线上验证和统计，在l1层命中缓存的概率是64％，l2和l3是34％，到db层的概率是2％，大部分都可以缓存覆盖，大大降低了db的性能压力。而根据线上的流量的压力，l1层是可以动态调整的，也就是说根据实际情况一旦流量起来了，可以动态将l1层调整变大，而流量减少之后可以动态将l1层减少。
[0192]
在存储介质方面，l1层采用memcached这种高性能的二进制简单kv存储，因为热点型数据往往都不会是很复杂的场景，因而使用的简单的kv模式足以应对，例如热门医生信息，名医的数量是有上限的，不可能一直激增。而l2和l3层则采用redis这样具有复杂存储结构的存储介质，包括团队关系这样的信息可以使用哈希结构，用来保存一个团队中的团队成员信息。
[0193]
状态区域5065：在互联网医院订单列表服务中有大量的判断是否的业务，例如是否已经开具处方、是否阅读对方消息、是否提交诊断等。在使用redis存储介质实现时，由于存储量过大，无法满足需求。因而本技术的方案采用了布隆过滤器的方式，大大的减少了存储量。
[0194]
例如，采用了布隆过滤器的方式判断消息是否被阅读的过程可以包括：如图11所示，将消息的标识用三个哈希函数映射到3个位置(消息1的映射位置)，如果3个位置的取值
都是1，则认为消息1被阅读，如果一个位置的取值是0，则认为消息1没有被阅读。例如，将消息1的标识用三个哈希函数映射到3个位置(消息1的映射位置)，该3个位置的取值都是1，认为消息1被阅读。
[0195]
计数区域5066用于存储计数数据，其中，计数数据可以包括：历史接单量、今日接单量、最近两个小时接单量、目前总共服务过多少患者、目前加入的团队数量等。大量的计数业务在订单列表服务中存在，本方案在此处提供两种方案，一种是db cache，一种是纯cache，第一种方案以历史接单量为例子，将过往单量以每日为单位存储于db中，而今日缓存动态计算，如果想查看今日接单量则利用缓存即可，而如果想查看历史总单量则将db中的数据之和和今日的数据量相加即可，但是这种方案应对小数据量还可以，但是一旦出现数据倾斜，例如某位名医的历史单量很复杂，多次从db中读取计数数据也很耗费数据库性能，甚至有可能造成灾难。纯cache方式利用了redis的自增指令(incr)和自减指令(decr)，对于计数大于0的数据数据库存储，而计数为0的并不需要存储，这样节约了大量的内存空间，而为了防止缓存宕机，一定是先落db再落入缓存，以防止数据错乱和丢失，这样可以兼顾安全和性能。
[0196]
本技术实施例提供了一种工具包，其可以在操作缓存的时候自动上报日志埋点，包括日志标识、时间戳、数据来源、数据快照等基本信息，并通过内部高速jdq来使用。
[0197]
本技术实施例的界面监控功能，根据日志上报，将核心业务数据通过界面展示，用来监控健康程序、系统风险，若有问题自动通知运维人员。
[0198]
本技术实施例提供的数据处理方法，通过前置计算、高效应答、数据可视的综合解决方案具有前置计算、异步处理，异构缓存、高效应答，统一平台、数据可视的特点。
[0199]
前置计算、异步处理
[0200]
本方案大部分的操作均是mq异步，前置计算将数据存储好等待用户过来获取，用户执行操作时其实就已经没有任何计算逻辑，仅仅是读取操作，这样的方式才能保证每次应答都小于40ms。
[0201]
异构缓存、高效应答
[0202]
本方案中的所有数据均备份在db或者es中，数据结构迥异，为了高效应答，均将数据拉平，以kv的形式异构于缓存介质中，从而高效应答。
[0203]
统一平台、数据可视
[0204]
为了更好的监控系统健康情况，特意将系统全流程进行覆盖，上报埋点数据，数据可视，启用矫正动作，及时发现问题及时矫正，规避了风险。
[0205]
为了实现本技术实施例提供的数据处理方法，本技术实施例的一种数据处理装置，下面结合图12所示的数据处理装置的结构示意图进行说明。
[0206]
如图12所示，数据处理装置120包括：接收单元1201、确定单元1202和处理单元1203。其中：
[0207]
接收单元1201，用于接收第一请求，并且确定所述第一请求请求处理的目标数据的数据类型；
[0208]
确定单元1202，用于基于目标数据的数据类型从缓存包括的至少一个区域中，确定目标区域；所述至少一个区域中，不同区域用于存储不同数据类型的数据；
[0209]
处理单元1203，用于在所述目标区域中对所述目标数据，执行所述第一请求对应
的处理。
[0210]
在一些实施例中，接收单元1201，还用于通过第一任务接收所述第一请求，并且确定所述第一请求请求处理的目标数据的数据类型；
[0211]
处理单元1203，还用于通过第二任务在所述目标区域中对所述目标数据，执行所述第一请求对应的处理；所述第一任务与所述第二任务不同。
[0212]
在一些实施例中，处理单元1203，还用于：
[0213]
若所述目标区域为第一区域，所述第一区域用于存储订单数据；在所述第一区域中确定第一目标子区域；所述队列区域中的不同子区域用于存储不同用户的订单数据；
[0214]
在所述第一目标子区域中对所述目标数据，执行所述第一请求对应的处理。
[0215]
在一些实施例中，处理单元1203，还用于：
[0216]
若所述目标区域为第二区域，所述第二区域用于存储静态数据；确定所述目标数据的访问状态；
[0217]
基于所述访问状态，在所述第二区域中确定第二目标子区域；所述第二区域中的不同子区域用于存储不同访问状态的静态数据；
[0218]
在所述第二目标子区域中对所述目标数据，执行所述第一请求对应的处理。
[0219]
在一些实施例中，处理单元1203，还用于：
[0220]
若所述访问状态为表征热点数据的第一状态，确定第一子区域为所述第二目标子区域；所述热点型数据的访问频率大于或等于第一频率阈值；所述第一子区域通过第一中间件缓存数据；
[0221]
若所述访问状态为表征为非热点数据的第二状态，确定第二子区域为所述第二目标子区域；所述非热点型数据的访问频率小于所述第一频率阈值；所述第二子区域通过第二中间件缓存数据；所述第二中间件的数据处理速率小于所述第一中间件的数据处理速率。
[0222]
在一些实施例中，处理单元1203，还用于：
[0223]
若所述目标区域为第三区域，所述第三区域用于存储状态数据；通过布隆过滤器在所述第三区域中对所述目标数据，执行所述第一请求对应的处理。
[0224]
在一些实施例中，处理单元1203，还用于：
[0225]
若所述目标区域为第四区域，所述第四区域用于存储计数数据；所述第一请求为写入请求，确定所述目标数据大于或等于1，在所述第四区域中写入所述目标数据。
[0226]
需要说明的是，本技术实施例提供的数据处理装置包括所包括的各单元，可以通过电子设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(cpu，central processing unit)、微处理器(mpu，micro processor unit)、数字信号处理器(dsp，digital signal processor)或现场可编程门阵列(fpga，field-programmable gate array)等。
[0227]
以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本技术装置实施例中未披露的技术细节，请参照本技术方法实施例的描述而理解。
[0228]
需要说明的是，本技术实施例中，如果以软件功能模块的形式实现上述的数据处理方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基
于这样的理解，本技术实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本技术各个实施例所述方法的全部或部分。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read only memory，rom)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本技术实施例不限制于任何特定的硬件和软件结合。
[0229]
第三方面，本技术实施例提供一种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述实施例中提供的数据处理方法中的步骤。
[0230]
下面结合图13所示的电设备130的结构图进行说明。
[0231]
在一示例中，如图13所示，所述电子设备130包括：一个处理器1301、至少一个通信总线1302、用户接口1303、至少一个外部通信接口1304和存储器1305。其中，通信总线1302配置为实现这些组件之间的连接通信。其中，用户接口1303可以包括显示屏，外部通信接口1304可以包括标准的有线接口和无线接口。
[0232]
存储器1305配置为存储由处理器1301可执行的指令和应用，还可以缓存待处理器1301以及电子设备中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(flash)或随机访问存储器(random access memory，ram)实现。
[0233]
第四方面，本技术实施例提供一种存储介质，也就是计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中提供的数据处理方法中的步骤。
[0234]
这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本技术存储介质和设备实施例中未披露的技术细节，请参照本技术方法实施例的描述而理解。
[0235]
应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本技术的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一些实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本技术的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
[0236]
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
[0237]
在本技术所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或
可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
[0238]
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
[0239]
另外，在本技术各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
[0240]
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(read only memory，rom)、磁碟或者光盘等各种可以存储程序代码的介质。
[0241]
或者，本技术上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本技术各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、rom、磁碟或者光盘等各种可以存储程序代码的介质。
[0242]
以上所述，仅为本技术的实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。