一个线程接收数据，存入list里,另一个线程从list里去数据入库，接收的快，入库慢，list里的数据一直在增加，内存最后被耗尽了，如何解决？ 数据是行情数据，入库的先后顺序不能变
1、设置一个自增变量，接收一条推送数据自增1用于list自定义列，可以在数据库对应列增加对应唯一ID值并设置索引。
2、随后开设几条线程，如3条线程，线程tag初值分别1、2、3，根据初值从小到大启动，每存一条数据自增线程数的值，3条增3，4条增4以此类推。
3、sql在插入语句增加一个ID连续性的判断（if exists(select 0 from [tb] where ID=@id-1)...），插入前须存在ID减1的条目存在，否则delay若干毫秒后再插入，重复N次。
你不在数据库设置ID也行，那就要判断每线程插入的ID是否是当前list最小值。
4、每线程插入完成最后，删除对应ID的list条目。
以上以供参考
保存数据新开线程去保存，最好用线程池，核心线程数为1，最大线程数也为1，然后缓存队列设置大一点。
可以试试用两个list存数据, 接收数据的时候可以随机存储到任意一个list里, 然后用两个线程分别对这两个list进行入库操作,
不过有个问题就是list并发修改可能会有问题,同步又会影响性能.
接收的数据可以不存储在List里，接过来按照时间顺序存储到另一个数据表里(比如叫data)，另一个线程从这个数据表里读取数据进行入库。入库后就删掉原数据，
如果data表的数据条数大于一定数量，可以继续往别的表里存储。
这个场景看起来像是一个数据库 IO 瓶颈的问题。所以我首先想到的是使用 SqlBulkCopy 来提高写入性能。这个效率比起一条一条写入实在是高太多太多。
另外我还想到通过使用独立的 Redis 服务器来缓解主服务器的压力。不过这个只是起到缓解，主要还是使用批量写入来提高效率。以前我们对接币安接收行情数据时也是这样做的。