一个服务（A）接收串口的数据，另一个服务(B)解析收到的数据并存入数据库。我现在采用的方式：
A接到数据存入数据表
B服务监听数据表发现有数据则取出解析
不知有没有更高效和可靠的方法。
------解决思路----------------------
可以 在 把 A 中接受的数据 存储到 队列中 或者 数据库 中，然后单独开启一个线程 去处理 ，不用单独写个服务也 可以吧
------解决思路----------------------
你不如用多线程,而不是用2个进程
------解决思路----------------------
典型的生产者-消费者问题
可以单个进程中使用多线程，
接收者线程将数据放入队列中，解析线程从队列中读取数据进行解析。
队列要加锁进行数据同步
光看需求感觉不需要用多个进程。
------解决思路----------------------
A接到数据存入数据表
B服务监听数据表发现有数据则取出解析
既然你A无论如何都要把数据存个地方,直接存数据库不就得了,还要B干啥
------解决思路----------------------
A和B是两个无关的进程？
如果是一个程序中的，那么A直接调用B中的方法的代码不就行了，把数据参数传过去就行了。用慢1000倍数据库来做中介，是怕.net程序方法传递参数的机制不可靠么？
------解决思路----------------------
如果是跨进程的，那么B应该是在服务的消息的接口上有I/O参数设置。就好像是你不论在入门书上哪一种服务的设计上都看到它面向输入输出实体参数的。那么A就应该把数据作为参数来调用B服务。就服务调用的设计上而言（而不是持久化保存而言），也谈不上数据库。
------解决思路----------------------
你多虑了
用2个进程来代替1个进程的功能,智能是故障节点又多了一个,更容易出问题了而已
没来得及处理的数据丢失了,这算事??
假如你每秒要通信10次,你是纠结某1秒里的其中一次通信的数据丢了
但是在接下来的5个小时内,如果没人发现这程序崩溃了不在运行,那么5小时之内的数据其实都丢了的,差那一次两次的??
------解决思路----------------------
串口传输本来也无法保证精确传输,数据不会错乱.
你需要自己通过协议去做数据校验,重发的机制
通信中丢失数据是很正常的事情,不要企图24*7小时每个数据都不丢失,那是不可能的
------解决思路----------------------
不管是串口通信还是TCP通信,你都无法保证每个数据都能正确的送达.需要自己做冗余校验,重发.
你想在9600bps下这么高的传输速度里实现完全无错误
概率可能比整个城市内1星期无车祸的概率还要小.
------解决思路----------------------
我们来多说一下所谓“服务（A）接收串口的数据”的效率问题。实际上.net应用程序中接收数据有两层架构，一层是接收到一组byte字节，另一层是接收到一个完整的应用命令并开始解析。这两层应该是异步的。第一层接收到一些byte字节，把内容放到一个List<byte> 集合或者 MemoryStream 对象中然后向系统线程池注册一个“处理接收结果”的任务就可以返回了，就去继续接收其它信息了，绝不是等待着确实开始调用B以后才返回。
在“处理接收结果”这个方法中，它判断是否收到了完整的消息，如果收到了就开始调用B。这时候绝不会阻塞接收数据操作。
------解决思路----------------------
这就意味着你在A调用B的同时要（异步地）存一份到数据库。将来A可能在一段时间之后再次调用B。
而绝不是用数据库做通讯中介的意思！
------解决思路----------------------
数据库是用来做持久化的，而不是用来做通讯的。要保持这个基本的设计素质，那么你就不会犯“后面改用数据表实现共享”这类问题了。