这是一个创建于 1847 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司上了一个项目，打算自己做一套多客服系统，前期公司内部自用，后期了打算接入替换之前购买的客服系统。 目前我们要配合做服务端，服务端编程语言不知道选择哪个？数据库选择哪个？
- 要求就是高并发，一秒上百个客服接入（甚至峰值 1-2 千），多用户同时聊天传输文件。
- 目前团队技术已有或者可以通过学习掌握的编程语言：Go，Python，PHP，Java，JavaScript （ nodejs ）
- 数据库 MongoDB，MySql，MsSql，PostgreSQL
- 还有哪些需要注意的坑
非常感谢！
 |
1
TapCode OP 有大佬给个思路没？用哪个语言+数据库更合适？，感谢！
|
 |
2
tadtung 2019-12-04 11:18:19 +08:00  1
客服系统的话，php+mysql 的挺多的。 java python 的开源客服系统也不少，看你自己喜欢了。
如果想低成本，国外买一套或者这开源的 做二开就行。 |
|
4
tadtung 2019-12-04 11:22:01 +08:00 1
@TapCode 名字忘了，也是几年前二开、汉化过，你 google 和 GitHub 搜一下，时间比较久了，现在国外开源的应该更多。
|
 |
5
jimrok 2019-12-04 11:27:10 +08:00 1
java 吧，如果你的团队 java 的人多，数据库留存的话，Mysql 和 PostgreSQL 都可以。
|
 |
6
misaka19000 2019-12-04 11:29:24 +08:00 1
你目前的性能还不到需要考虑语言的程度，所以选你一个你最熟悉的就行了
|
|
7
tadtung 2019-12-04 11:30:49 +08:00 1
@TapCode 刚看了一下，php livechat 现在依旧还在，我以前二开和汉化的就是这个。
另外 Rocket.Chat 这个应该是最热门的。 https://github.com/RocketChat/Rocket.Chat 还有其他很多的，你自己搜下就行。 |
 |
8
opengps 2019-12-04 11:33:31 +08:00 1
峰值 1000-2000，这得相当大型的系统了
|
|
9
opengps 2019-12-04 11:34:29 +08:00 1
这个业务规模下，架构的优秀指标要比语言的选型指标更重要了
|
|
10
TapCode OP @opengps
系统不是很大，就是商城的客服，目前也就赶上店庆和双十一的时候能达到峰值 1-2k，平日里每天的高峰期也就 3-5 百，闲暇时段 几十个而已。 @tadtung 非常感谢，这边去看一下 @misaka19000 确实是，但是公司开发好以后打算直接移植替换之前买的 saas 版的客服系统，所以一开始还是估算的大一些，语言选的好一些，这样后期麻烦也少。 @jimrok 感谢 |
 |
11
lhx2008 2019-12-04 11:42:49 +08:00 via Android
同时一两千和一秒一两千可不是一个概念吧，同时一两千挂个消息队列，一秒能出 50 个消息算多了，直接写 mysql 也不慢
|
 |
12
janxin 2019-12-04 11:44:38 +08:00
为什么不买现成的...
|
|
13
lhx2008 2019-12-04 11:46:02 +08:00 via Android
所以相比高性能，可靠性才是重点，怎么合理地容灾，这个又是一个基础设施的问题了
|
 |
14
lc7029 2019-12-04 11:50:11 +08:00
追求安全和高可用的话，Oracle RAC。
重点是买完授权出问题有人背锅 |
|
15
TapCode OP |
 |
16
npe 2019-12-04 11:57:04 +08:00 via iPhone
Java 吧， 生态完善。IM 用 Netty，DB 用 newSQL，MQ 用 RocketMQ。后期也顶得住。
|
 |
17
hzgit 2019-12-04 12:04:27 +08:00
用什么语言取决于成本，团队的学习成本，后期的维护成本，招人的成本等等等等
|
 |
18
zzcworld 2019-12-04 12:10:02 +08:00
Go 加 Postgresql 就行
|
 |
19
815979670 2019-12-04 14:16:40 +08:00
建议 Go 不建议 php+swoole
|
 |
20
laminux29 2019-12-04 14:21:53 +08:00 1
1.客服系统的业务有点像火车站售票大厅，单个用户在窗口买票时，无论流量还是 CPU 压力，其实并不大，而且每个业务实例之间的关联度还很低，多买票窗口的并行度非常高。麻烦的地方只有一个，就是新用户进来时，需要排队，同时快速通过负载均衡选一个空闲的窗口进行买票。
2.通过上诉分析，技术选型也就简单了。最重要的是前端排队，要能撑起来 1-2k 的峰值。建议 C++，选择一个轻量级内存数据库模块，来做排队前级，后级就是 java 或 Python 甚至 PHP 做的窗口，数据库用龟速 mysql 都行，流量大时多开几个节点。 |
 |
21
PureWhiteWu 2019-12-04 14:24:21 +08:00
Go 最合适。
|
|
22
PureWhiteWu 2019-12-04 14:25:17 +08:00 1
Go + MySQL，不选 pgsql 的原因就是生态不如 MySQL。
选择的时候生态很重要，pgsql 虽然理论上比 MySQL 好，但是各种支持、工具之类的都不如 MySQL。 |
 |
23
wangyzj 2019-12-04 14:40:15 +08:00
语言只是手段
选择最适合团队的就好了 |
Select Language