最后还是想问下，大并发和数据量的情况下，是直接连接数据库效率高还是使用网络通信的方式效率高呀？项目对实时性要求较高。
11 个解决方案
#1
高并发高负载不是直接连数据库去解决的。软件是昂贵的，硬件是廉价的。如果你的程序牺牲一半的性能，但是可以在部署到10个计算机乃至100个计算机上能取得近似线性的加速比，这样可伸缩性的程序，比起一个只能在1、2台计算机上运行，但是快5倍的程序更有效。不要用业余的思维方式去思考程序！
#2
要是对性能要求高，当然是用 socket 了， webservice肯定没有你自己写 socket 来得快，但是这个就比较考验写 socket 的水平了
#3
看具体的需求选择如何优化吧, 不访问数据库, 可以采用 访问缓存的方式. 客户端与服务器采用Socket或者 UDP广播(每个客户端所需要的数据内容相同时, 可采用UDP)
#4
如果没有什么缓存啊，重用数据之类的要求下，直接连数据库是最快的。。
#5
这个东西理解的层次是不同的。
最低级地，是不能把关系数据库暴露在公网（或者大企业的单个小网段外），而应该通过自己开发的 专用业务应用服务对客户端提供服务。
其次低级地，既然需要做c/s程序，干脆就做成在互联上各种“较差、教复杂”的网络环境条件下，也能畅通无阻地运行的网络系统。比如你用到的QQ就可以在全球各种内网内（包括手机内）使用。
高级一点的层次，就有丰富的专业性的设计知识了。简单来说，比如说一个网络游戏软件，可以同时让素不相识上千人在同一个虚拟人生世界中相遇、做任务、交互。此时有些人可能就以为，各种操作都是客户端把数据Insert到服务器的SQL Server数据库，然后别的客户端都去 select .... from ..... 来判断自己是否与别人相遇、做任务、交互。这就是纯粹是开玩笑了。但是很多人都是这样以为的，因为他仅仅见过OA程序，没有见过真正的实时业务系统的服务器设计。但是你就可以想象一下，真正的实时业务系统，比如说几千人同时在线的网游，比如说大企业的几百个工作一千人同时在线的工作流系统，比如说各种企业即时通讯工具等等，比如说支持几亿手机IP方式通讯的计算机网络，哪怕就是一个快递公司用来显示和协调各快递员的线路地图系统，等等，有哪些是用简单地“客户端程序调用SQL Server的客户端驱动来对其增删改查”就能做好敏捷的业务服务器的呢？
设计一个真正的业务服务器时考虑的是业务服务和业务实体，也就是业务逻辑层，而根本不是什么sql语句“增删改查”。如果是了解这种业务服务器系统设计的人，他又怎么会去纠结“是否调用客户端驱动来对SQL Server增删改查”呢？只有做惯了小办公室内的OA程序的人才习惯于这样考虑c/s系统架构。
#6
随便举出九牛一毛的一点，比如说要实时跟踪各个快递员的位置信息，那么在内存里设置一个 List<Courier> 集合就行了，每一个快递员都有经纬度信息。这类东西绝不用速度慢几百倍的数据库来实现的，数据库只是用来异步地做持久化备份的，而不是唯一地用来支撑实时业务系统的。
#7
关于web service，除非给别人的遗老系统连一下的时候，否则我是不用的。
现在各种通讯方式都讲求轻量级，传递json字符串消息就行了，没有必要做高度复杂的封装和解析。
现在各种通讯方式都讲求轻量级，传递json字符串消息就行了，没有必要做高度复杂的封装和解析。
#8
要效率，就必须考虑缓存，显然数据库是没法处理缓存的。其它还有安全性等，都要求不能直接连接数据库。
#9
编程的最终目的，当然是越简单越好。能不写代码就不写代码，能不new什么对象就不new对象。能不设计什么class、interface就不要抽象。能不使用高级的c/s概念来架构时，就直接调用关系数据库的客户端驱动好了。
但是实践中， 需要的时候，这些都会被熟练的设计人员大量使用。
而有些人，自己没有把自己放到那种更高要求的公司或者项目中，仅仅因为时髦而纠结于那些“技术”，就很难体会到实践者的乐趣。
但是实践中， 需要的时候，这些都会被熟练的设计人员大量使用。
而有些人，自己没有把自己放到那种更高要求的公司或者项目中，仅仅因为时髦而纠结于那些“技术”，就很难体会到实践者的乐趣。
#10
建议用中间层，而不是直连。一是安全问题，二是维护方便。可以用webservice，简单，或者wcf
#11
谢谢大家的解答！
#1
高并发高负载不是直接连数据库去解决的。软件是昂贵的，硬件是廉价的。如果你的程序牺牲一半的性能，但是可以在部署到10个计算机乃至100个计算机上能取得近似线性的加速比，这样可伸缩性的程序，比起一个只能在1、2台计算机上运行，但是快5倍的程序更有效。不要用业余的思维方式去思考程序！
#2
要是对性能要求高，当然是用 socket 了， webservice肯定没有你自己写 socket 来得快，但是这个就比较考验写 socket 的水平了
#3
看具体的需求选择如何优化吧, 不访问数据库, 可以采用 访问缓存的方式. 客户端与服务器采用Socket或者 UDP广播(每个客户端所需要的数据内容相同时, 可采用UDP)
#4
如果没有什么缓存啊，重用数据之类的要求下，直接连数据库是最快的。。
#5
这个东西理解的层次是不同的。
最低级地，是不能把关系数据库暴露在公网（或者大企业的单个小网段外），而应该通过自己开发的 专用业务应用服务对客户端提供服务。
其次低级地，既然需要做c/s程序，干脆就做成在互联上各种“较差、教复杂”的网络环境条件下，也能畅通无阻地运行的网络系统。比如你用到的QQ就可以在全球各种内网内（包括手机内）使用。
高级一点的层次，就有丰富的专业性的设计知识了。简单来说，比如说一个网络游戏软件，可以同时让素不相识上千人在同一个虚拟人生世界中相遇、做任务、交互。此时有些人可能就以为，各种操作都是客户端把数据Insert到服务器的SQL Server数据库，然后别的客户端都去 select .... from ..... 来判断自己是否与别人相遇、做任务、交互。这就是纯粹是开玩笑了。但是很多人都是这样以为的，因为他仅仅见过OA程序，没有见过真正的实时业务系统的服务器设计。但是你就可以想象一下，真正的实时业务系统，比如说几千人同时在线的网游，比如说大企业的几百个工作一千人同时在线的工作流系统，比如说各种企业即时通讯工具等等，比如说支持几亿手机IP方式通讯的计算机网络，哪怕就是一个快递公司用来显示和协调各快递员的线路地图系统，等等，有哪些是用简单地“客户端程序调用SQL Server的客户端驱动来对其增删改查”就能做好敏捷的业务服务器的呢？
设计一个真正的业务服务器时考虑的是业务服务和业务实体，也就是业务逻辑层，而根本不是什么sql语句“增删改查”。如果是了解这种业务服务器系统设计的人，他又怎么会去纠结“是否调用客户端驱动来对SQL Server增删改查”呢？只有做惯了小办公室内的OA程序的人才习惯于这样考虑c/s系统架构。
#6
随便举出九牛一毛的一点，比如说要实时跟踪各个快递员的位置信息，那么在内存里设置一个 List<Courier> 集合就行了，每一个快递员都有经纬度信息。这类东西绝不用速度慢几百倍的数据库来实现的，数据库只是用来异步地做持久化备份的，而不是唯一地用来支撑实时业务系统的。
#7
关于web service，除非给别人的遗老系统连一下的时候，否则我是不用的。
现在各种通讯方式都讲求轻量级，传递json字符串消息就行了，没有必要做高度复杂的封装和解析。
现在各种通讯方式都讲求轻量级，传递json字符串消息就行了，没有必要做高度复杂的封装和解析。
#8
要效率，就必须考虑缓存，显然数据库是没法处理缓存的。其它还有安全性等，都要求不能直接连接数据库。
#9
编程的最终目的，当然是越简单越好。能不写代码就不写代码，能不new什么对象就不new对象。能不设计什么class、interface就不要抽象。能不使用高级的c/s概念来架构时，就直接调用关系数据库的客户端驱动好了。
但是实践中， 需要的时候，这些都会被熟练的设计人员大量使用。
而有些人，自己没有把自己放到那种更高要求的公司或者项目中，仅仅因为时髦而纠结于那些“技术”，就很难体会到实践者的乐趣。
但是实践中， 需要的时候，这些都会被熟练的设计人员大量使用。
而有些人，自己没有把自己放到那种更高要求的公司或者项目中，仅仅因为时髦而纠结于那些“技术”，就很难体会到实践者的乐趣。
#10
建议用中间层，而不是直连。一是安全问题，二是维护方便。可以用webservice，简单，或者wcf
#11
谢谢大家的解答！