企业内部服务器选取方案，用作ERP服务器。最多100人并发(30-80人)， 知道的大大们给一些建议，

看了下你和别人的对答

百人并发访问，又是企业核心的ERP系统，不要省钱，一定要万元以上。

ERP的特点是主要进行数据库的查询、计算和数据更新

如果并发多，或者查询复杂，对CPU、硬盘IO吞吐要求都比较高，所以单硬盘是万万不能的

考虑数据安全性，最少要有RAID，考虑数据吞吐，应该用SAS硬盘，这样几块硬盘就差不多万元了

至于你说的网卡，其实不用关心，因为数据主要是在服务器进行计算，传输出来的数据很少，多网卡是针对Vlan等特殊网络需求使用的，一般单网卡足够使用

推荐的话，我觉得联想的不错，虽然贵点，但是用的单位挺多

你可以选择塔式或者机架式，根据你们现场情况，CPU我觉得双U的应该适合你们，总费用2万多就差不多了

具体型号你可以上官网看下，比如RD630，肯定满足你们要求，不过价格稍微贵一点，3万来的，更低一点的型号也可以，但不要用入门的那种。

处理高并发的六种方法

1：系统拆分，将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，这样就可以抗高并发。

2：缓存，必须得用缓存。大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并发啊。没问题的。所以你可以考的虑考虑你的项目里，那些承载主要请求读场景，怎么用缓存来抗高并发。

3：MQ(消息队列)，必须得用MQ。可能你还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对搞挂你的系统，人家是缓存你要是用redis来承载写那肯定不行，数据随时就被LRU(淘汰掉最不经常使用的)了，数据格式还无比简单，没有事务支持。所以该用mysql还得用mysql啊。那你咋办？用MQ吧，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是ok的。

4：分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来抗更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高sql跑的性能。

5：读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。

6：solrCloud:

SolrCloud(solr 云)是Solr提供的分布式搜索方案，可以解决海量数据的 分布式全文检索，因为搭建了集群，因此具备高可用的特性，同时对数据进行主从备份，避免了单点故障问题。可以做到数据的快速恢复。并且可以动态的添加新的节点，再对数据进行平衡,可以做到负载均衡：

　　服务程序最为关键的设计是并发服务模型，当前有以下几种典型的模型：

　　- 单进程服务，使用非阻塞IO

　　使用一个进程服务多个客户，通常与客户通信的套接字设置为非阻塞的，阻塞只发生在select()、poll()、epoll_wait()等系统调用上面。这是一种行之有效的单进程状态机式服务方式，已被广泛采用。

　　缺点是它无法利用SMP(对称多处理器)的优势，除非启动多个进程。此外，它尝试就绪的IO文件描述符后，立即从系统调用返回，这会导致大量的系统调用发生，尤其是在较慢的字节传输时。

　　select()本身的实现也是有局限的：能打开的文件描述符最多不能超过FD_SETSIZE，很容易耗尽；每次从select()返回的描述符组中扫描就绪的描述符需要时间，如果就绪的描述符在末尾时更是如此（epoll特别彻底修复了这个问题）。

　　- 多进程服务，使用阻塞IO

　　也称作 accept/fork 模型，每当有客户连线时产生一个新的进程为之服务。这种方式有时是必要的，比如可以通过操作系统获得良好的内存保护，可以以不同的用户身份运行程序，可以让服务运行在不同的目录下面。但是它的缺点也很明显：进程比较占资源，进程切换开销太大，共享某些信息比较麻烦。Apache 13就使用了这种模型，MaxClients数很容易就可以达到。

　　- 多线程服务，使用阻塞IO

　　也称之 accept/pthread_create模型，有新客户来时创建一个服务线程而不是服务进程。这解决了多进程服务的一些问题，比如它占用资源少，信息共享方便。但是麻烦在于线程仍有可能消耗光，线程切换也需要开销。

　　- 混合服务方式

　　所谓的混合服务方式，以打破服务方和客户方之间严格的1:1关系。基本做法是：

　　新客户到来时创建新的工作线程，当该工作线程检测到网络IO会有延迟时停止处理过程，返回给Server一个延迟处理状态，同时告诉 Server被延迟的文件描述符，延迟超时时间。Server会在合适的时候返回工作线程继续处理。注意这里的工作线程不是通过 pthread_create()创建的，而是被包装在专门用于处理延迟工作的函数里。

　　这里还有一个问题，工作线程如何检测网络IO会有延迟？方法有很多，比如设置较短的超时时间调用poll()，或者甚至使用非阻塞IO。如果是套接字，可以设置SO_RCVTIMEO和SO_SNDTIMEO选项，这样更有效率。

　　除了延迟线程，Server还应提供了未完成线程的支持。

　　如有有特别耗费时间的操作，你可以在完成部分工作后停止处理，返回给Server一个未完成状态。这样Server会检查工作队列是否有别的线程，如果有则让它们运行，否则让该工作线程继续处理，这可以防止某些线程挨饿。

　　典型的一个混合服务模型开源实现ServerKit

　　Serverkit的这些线程支持功能可简化我们的服务程序设计，效率上应该也是有保证的。

　　2 队列(queue)

　　ServerKit提供的队列是一个单向链表，队列的存取是原子操作，如果只有一个执行单元建议不要用，因为原子操作的开销较大。

　　3 堆(heap)

　　malloc()分配内存有一定的局限，比如在多线程的环境里，需要序列化内存分配操作。ServerKit提供的堆管理函数，可快速分配内存，可有效减少分配内存的序列化操作，堆的大小可动态增长，堆有引用计数，这些特征比较适合多线程环境。目前ServerKit堆的最大局限是分配单元必须是固定大小。

　　4 日志记录

　　日志被保存在队列，有一个专门的线程处理队列中的日志记录：它或者调用syslog()写进系统日志，或者通过UDP直接写到远程机器。后者更有效。

　　5 读写锁

　　GNU libc也在pthreads库里实现了读写锁，如果定义了__USE_UNIX98就可以使用。不过ServerKit还提供了读写锁互相转换的函数，这使得锁的应用更为弹性。比如拥有读锁的若干个线程对同一个hash表进行检索，其中一个线程检索到了数据，此时需要修改它，一种办法是获取写锁，但这会导致释放读锁和获取写锁之间存在时间窗，另一种办法是使用ServerKit提供的函数把读锁转换成写锁，无疑这种方式更有效率。

　　除了以上这些功能，ServerKit还提供了数据库连接池的管理（当前只支持MySQL）和序列化（Sequences），如感兴趣可参见相关的API文档。

　　二、ServerKit服务模块编写

　　ServerKit由3部分组成：server程序，负责加载服务模块、解析配置文件、建立数据库连接池；libserver，动态链接库，提供所有功能的库支持，包括server本身也是调用这个库写的；API，编程接口，你编写的服务模块和ServerKit框架进行对话的接口。

　　ServerKit需要libConfuse解析配置文件，所以出了安装ServerKit，还需要安装libConfuse。关于libConfuse可参考 http://wwwnongnuorg/confuse/ 。

　　下面我们看一个简单的服务模块FOO：

　　#include <confuseh>

　　#include <serverh>

　　static long int sleep_duration;

　　static int FOO_construct()

　　{

　　fprintf(stderr, "FOO_construct\n");

　　return 1;

　　}

　　static int FOO_prestart(cfg_t configuration)

　　{

　　fprintf(stderr, "FOO_prestart\n");

　　return 1;

　　}

　　static void FOO_operator(void foobar)

　　{

　　fprintf(stderr, "FOO_operator\n");

　　for(;;) sleep(sleep_duration);

　　return NULL;

　　}

　　static void FOO_report(void)

　　{

　　fprintf(stderr, "FOO_report\n");

　　}

　　static cfg_opt_t FOO_config[] = {

　　CFG_SIMPLE_INT("sleep_duration", &sleep_duration),

　　CFG_END()

　　};

　　static char FOO_authors[] = {"Vito Caputo <vcaputo@pengarucom>", NULL};

　　SERVER_MODULE(FOO,0,0,1,"Example module that does nothing but sleep")

　　按以下方法编译：

　　$ gcc -c -fPIC -pthread -D_REENTRANT -g FOOc

　　$ gcc -shared -lserver -lconfuse -lpthread -g -e __server_module_main -o FOOso FOOo

　　-e选项指定程序运行入口，这使得你可以直接在命令行敲 /FOOso 运行模块。

　　server程序根据环境变量SERVER_PERSONALITY_PATH定位主目录，并查找主目录下的c11n作为配置文件，动态加载的模块需放在主目录下的modules目录。

　　$ export SERVER_PERSONALITY_PATH=`pwd`

　　$ mkdir modules

　　$ cp FOOso modules

　　$ vi c11n

　　c11n的内容：

　　identity = "any_id"

　　FOO {

　　sleep_duration = 1;

　　}

　　identity标识server实例，用ps可看到程序名称形如serveridentity，本例为serverany_id。

　　执行server启动服务程序。

　　三、ServerKit其他功能缺陷

　　缺乏daemon模式；

　　只能运行在Linux box；

　　DB pool只支持MySQL；

　　Heap管理内存的功力有限

场景很重要，比如一万并发的qps还是tps，这完全不同的概念。

服务器做做优化，现在通过epoll支撑百万连接十万并发没什么瓶颈。但是，这只是网络层，如果落到具体业务，那就另当别论了。比如redis可以十万并发，因为只需要网络io和访问内存。但是如果有业务处理，挂上了数据库，走了kafka，并且再走redis，那就要具体问题具体分析了。

数据库单存qps，我们原来基准测试结果是可以支撑六万到八万左右，但是有事务的增删改绝对不是这个量级。

其实你需要的是一个基准测试的结果，例如tcp，http基准测试；tomcat基准测试；应用框架基准测试；redis基准测试；mysql基准测试等。

我们做过应用框架基准测试，基于springboot，测试接口没什么逻辑，就是直接查询sql并返回结果。基准测试结果是八核16G内存，跑两个实例，可以撑到8万并发左右，应该还有优化空间吧。

你这问题就和一天跑一百公里要个什么车一样，也不说什么路，也不说拉什么货

撇开场景扯性能，扯吞吐量，扯并发都是耍流氓

几台服务器加F5，一台不牢靠

看你什么样的场景，业务复杂度，就个静态页面，给你两台ng就搞定了

允许配置全站加速吗？另外需求不明确

32核128G内存

不可以，如果是短期高并发，建议考虑挂载负载均衡服务器。

C10kp……这是很经典的问题啊，一般nio就做到了。

要看性能要求了，如果只讨论并发数量，用异步网络模型，并发一万个链接没啥问题吧，只是数据处理不过来，大多数链接都是在等待结果而已。服务器配置1核8g差不多够了吧

肯定不可行，使用消息队列只能缓解对冷数据的访问压力，并不能降低对HTTP服务器的访问压力。多个设备请求HTTP资源，最终访问的都是HTTP服务器的本地或代理资源。消息队列中间件一般是为了缓解高并发访问请求对数据库的压力。