门禁消费机都是非多线程的

最近在做的项目与门禁系统进行交互，出现收集门禁数据不能及时的问题，门禁系统和后台服务器进行交互，主要通过心跳接口和上传数据接口，这两个接口都是硬件设备通过协议定好了接口端口和访问服务目录，必须严格按照其要求才能正确接收数据，门禁和服务器交互主要内容如下：

• 通讯协议：主要采用HTTP协议，用户主要是中大型企业，本身具备良好的网络通讯宽带，所以会有大宽带WiFi，采用HTTP协议是合理的。如果网络通讯宽带比较小应该考虑使用MQTT协议。

• 心跳接口，每次设备主动发送心跳到服务器对应接口，通过心跳请求，可以对设备的状态进行有效监控，判断其是否还在运行即离线或在线状态，然后服务器会在用户在服务后台增加人员名单和人员信息(人脸、卡、人员姓名等)以协议规定的格式下发到硬件设备中。

• 上传门禁打卡数据，设备会才去某种策略定时上传员工打卡数据到服务器的接收数据接口。

出现问题：

• 用户那边有个大数据看板，用户实时统计用户的考勤打卡数据，以便对人员考勤数据进行数据分析和挖掘，而大数据看板要求数据必须能够确保实时性，但我们写的后台程序由于在心跳响应上存在很多占用时间的 *** 作，比如每次心跳去获取数据库用户名单、进行延时等待等 *** 作，导致心跳响应速度花了很长时间，这样导致了设备上传门禁打卡数据不够实时。

• 硬件设备一般是采用C语言写的，一般不会是多线程并发处理的，因为一台硬件设备只会与一台服务器交互，不用考虑并发问题，服务器则不然要面对很多不同硬件设备的并发请求，故硬件设备的底层程序不会太复杂，一般就是一个主线程，故心跳功能和上传门禁打卡数据功能是串行处理的，故要保证上传门禁打卡数据的实时性：

1. 必须保证心跳功能尽可能短的响应时间，一些复杂耗时的 *** 作(I/O,数据库获取数据等)尽量避免在心跳处理，可以采用启用异步线程去处理(比如统计监控心跳功能)，而下发人员名单数据因为需要作为心跳响应同步进行，故可以考虑人员名单下发必须控制在非上下班打卡高峰期进行。
2. 人员下发的名单获取，应该考虑采用独立部署微服务和新应用程序独立获取，然后将其分门别类地存入缓存(redis等)，这样服务器在需要下发名单时只是通过缓存交互获取内存中的数据，无需进行数据库等I/O *** 作。