SQL Server多进程多线程并发情况下如何保证

Answer 1

1、多进程并发
在传统UNIX中较常用，针对每一种单独的业务逻辑的实例生成不同的线程进行处理。典型的程序实例是针对TCP的多个不同的客户端连接，fork出多个子进程进行处理，每一个客户端对应一个单独的子进程，在子进程处理退出后，由父进程回收其资源。
优点：各进程间的地址空间相互隔离，不会因为某些不当操作将整个应用搞挂。
业务逻辑代码简单清晰，代码平铺直叙，没有复杂的异步状态逻辑。
缺点：如果需要在进程间进行交互或者共享数据，需要使用IPC。
2、多线程并发
在现代操作系统windows、linux中很常用，针对单独的业务逻辑的不同的实例在同一个进程中创建多个线程进行并发处理。典型的例子是，TCP的多个客户端在同一个进程中处理，针对每个客户端都单独对应的线程进行交互，共享同一个进程的所有资源。
优点：共享进程空间，访问共享数据非常容易。
没有多的进程空间开销，线程上下文切换快，调度效率比多进程高。
业务逻辑代码简单清晰，代码平铺直叙，没有复杂的异步状态逻辑。
缺点：维护线程的工作由进程内部代码处理，比如线程数量，增加一定的复杂性。
线程间共享数据的竞争关系复杂，需要处理同步和死锁问题。
3、IO多路复用
即在单线程控制多个异步业务逻辑，也就是事件驱动多个业务的状态处理，典型的有windows中的消息处理机制，还有linux中的信号量处理。可以在单一线程中，处理多种不同的业务逻辑，比如同时处理用户输出，鼠标点击，窗口重绘和网络输入。
优点：所有业务实例的逻辑在单一线程中处理，排除代码时序BUG，理论上不存在竞争和死锁问题。
没有多的进程空间开销，也没有上下文切换问题，CPU利用率高。
共享进程空间，访问共享数据非常容易。
缺点：
线程需要管理多个不同实例的状态机，并正确处理对应事件导致不同状态的迁移。
业务种类多的情况下，需要人为代码控制多种状态机。
并发点越多造成状态越多，管理粒度越细， 业务逻辑代码不是顺序的，不容易维护和理解。
异步状态过多，造成资源管理较为复杂，容易产生资源泄漏。