大数据量、高效通信及入库程序设计的关键实现技术要求

 

1.1   大数据量、高效通信及入库程序设计的关键实现技术要求：
1.         业务需求：

1)         通信方式

TCP、UDP、串口；

2)         数据并发量

数据为文本，单包比较小，每秒稳定在200条左右，每分钟稳定在12000条左右。

3)         延时性

考虑到要进行视频同步叠加，延时性要小于2秒；

4)         完成性

不允许有数据丢失行为，允许异步补回；
2.         关键技术点

1.   所有业务记录，建立连续的自然数为唯一标识（唯一标识为1..999999999999999的连续自然数），系统通过连续的自然数唯一标识来进行业务记录的缺失分析和通信的确认请求、补抓请求标识；

2.   采用UDP通信时，首要考虑的是防止数据丢失，在目前的局域网网络环境下，丢包率极低（通过适量的补发请求完全可以抵消该影响），同时考虑到数据量比较大，而实时性又要求高，如果想不想丢包，就要适当建立大些的UDP通信接收缓冲区（如果是Tcp发送缓冲区也要大写），以免发生缓冲区数据因处理不及时而发生覆盖丢失（如果延时允许可以适当做些延时处理）；接收处理线程，要将通信接收缓冲区的数据不要做任何处理，直接放入缓冲区（缓冲区采用链表，不要采用数组等以免数据暂时堆积排序，而影响效率），有处理线程异步进行数据的处理，但是必须要处理多线程对缓冲区访问的线程同步和冲突问题。

3.   数据库入库效率，如果并发量大，效率要求比较高，就尽量在入库表不要建索引，可以建立一个子增长的主键，并按照增长列范围段对记录进行分区存储，确保入库效率稳定在指定的范围内，同时尽量较少对入库表的长时间操作动作，如查询等。采用将入库业务数据异步批量读取并写入到内存事务临时表或内存会话临时表，然后再进行格式化处理，格式化后的表必然要建立索引，为确保后续业务检索的效率，所以入库效率会随着数据量的增大而减慢，此时可以通过分区，来将格式化的效率控制在一定的范围内。

当然如果没有入库顺序问题（大部分应用场景下都有顺序要求），也可以采用批量提交或数据入库效率会更高。

4.   取顺序记录要注意的事项

select *fromsl_businessinfostreamtwhere rownum<10000andt.isformat=0 orderby t.writeid;

         如果Writeid不是主键，将先取记录再排序，造成不是想要的排序。