用memcache 来实现聊天室的可能性探讨.

Question

突然想起这么个话题,当然要做复杂的是肯定不行的，我们只探讨将文本通过memcache实现聊天应用的可能..
首先摆在我们面前的是这个key要怎么维护?有没有实现的可能?

Answer 1

由于需要记录聊天内容和聊天人的信息
所以每笔数据应该是一个“结构”而不是单一的值鉴于聊天内容是不可修改的，所以 key 并无实际意义，递增即可
至多是取时间值

Answer 2

有道理，還是老大經驗老到。這麼說還是可以實現一個聊天室的基本功能的，比起用數據庫(排除突然死機，停電的問題)在性能上應該要更勝一籌，我記得上次編譯過一個據說會將記錄寫到硬盤上的memcache的替代品叫啥來着，就這麼忘記了，下次好好看看那個東東。

Answer 3

研究过python的聊天室...关注一下

Answer 4

本来聊天室就是个蛋疼的功能。得耗费多少资本啊。没有这方面的经验，实现的方法有多种。把聊天数据存数据库或本地文件或memcache，显示数据会用到推送。听说还可以用socket来实现。 也没测试过。不知道哪种效率高。

Answer 5

上次我記得在啥地方看到新浪一個人說他用什麼技術實現了普通服務器同時在綫xxx萬的在綫接入,我就想是真的有這種神仙在地球上嗎?
國內我知道阿里集團的技術研發是可以說非常強大的,很給國人爭光啊.有很多東西，我們這輩子可能聽都不曾聽過...這個輸入法老是簡體繁體傻傻分不清楚我就懶得切換了，大家能看懂的將就看吧

Answer 6

用websocket做长连接是很不错的！

Answer 7

虽然不懂web, 但是跑fcgi做单独的聊天服务器是可行的.

Answer 8

这个不错,不过等HTML5真正普及吧。
目前做B/S聊天室个人感觉FLASH还靠点谱，至于后端memcached啥的，真的有关系么,一样很容易拖死web sever？其实问题很简单，如何保证页面端用户每说一句话不要重新socket连接web服务器。

Answer 9

C++的大牛都来了。其实原理都是相通的。  聊天室一种是长连接，一种ajax拉.其于浏览器的聊天室好像目前没有推技术(除非浏览器支持，有开放端口，本身是服务器。）但长连接而言，服务器的连接数据是有 限的。
而ajax，量级是巨大的。

Answer 10

除非浏览器或flash本身是服务器时，如有开放端口，推技术才可能成真。http是请求-响应式的。 是要是uri，都可请求。猜想QQ， 每个用户都有好友的端口中。
也是有两种方式实现： 一是有数据存中央数据库；二是一个用户发言，然后向群里广播。

Answer 11

memcached的替代品？ 
redis吧，数据放入内存，但也支持在硬盘上持久化保存，配置正常的情况下，性能大概是memcached的十倍（网上的数据，俺自己测没打到过，但5倍以上是确认的）。另外，做聊天室是可行的，并且也有类似的代码， redis官网有个示例，是完全用redis来做的模仿twiiter的页面。project名称好像叫“retwis”以前也看到过设计，一般key是用散列值即可吧，比如 用户名_时间 然后md5一下之类的...

Answer 12

QQ是p2p吧？服务器只通告双方打洞(UDP),然后聊天基本上就是两台客户机的事了，发文件也是。

Answer 13

时间戳做key由于mem 的value值是有大小限制的可以每过一段时间生成个key 然后内部是json格式例如 
每五分钟一个key 
然后把这五分钟内的聊天记录都放到mem中然后 用户登录根据当前的时间戳来查询 
不知道可否

Answer 14

呃，好吧，从目前的经验来看，如果单台服务器来做的话，私以为用长连接是不合适的，短连接做聊天室能够实现更多的访问量。假设一台16核心16G的服务器，Nginx + PHP-FCGI的话，大概可靠并发能达到3W，那么长连接，最多也就是3W用户喽？（3W是俺自己测试的情况，俺渣....不过另外也参考了张宴的blog，姑且国内nginx的先驱者吧）  但短连接的话，就看Nginx每秒最多的request和 后端存储每秒最多request的能力了以下是nginx和redis的单独 request能力 测试：
nginx，以phpinfo.php为测试内容./webbench -c 10000 -t 30 "http://127.0.0.1/test.php"
Webbench - Simple Web Bench 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.Benching: GET http://127.0.0.1/test.php
10000 clients, running 30 sec.Speed=230470 pages/min, 46263036 bytes/sec.
Requests: 115235 susceed, 0 failed.
Speed=230470 pages/min 估算的话， 大概就是每秒3841次请求喽redis：./redis-bench 
====== PING (inline) ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1100.00% <= 0 milliseconds
74074.07 requests per second====== PING ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1100.00% <= 0 milliseconds
73529.41 requests per second====== MSET (10 keys) ======
  10000 requests completed in 0.25 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 12.64% <= 1 milliseconds
99.51% <= 2 milliseconds
99.71% <= 3 milliseconds
100.00% <= 3 milliseconds
40160.64 requests per second====== SET ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 199.94% <= 1 milliseconds
100.00% <= 1 milliseconds
70422.54 requests per second====== GET ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1100.00% <= 0 milliseconds
73529.41 requests per second====== INCR ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 199.93% <= 1 milliseconds
100.00% <= 1 milliseconds
70422.54 requests per second====== LPUSH ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 199.87% <= 1 milliseconds
100.00% <= 1 milliseconds
71428.57 requests per second====== LPOP ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1100.00% <= 0 milliseconds
72992.70 requests per second====== SADD ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1100.00% <= 0 milliseconds
72463.77 requests per second====== SPOP ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1100.00% <= 0 milliseconds
73529.41 requests per second====== LPUSH (again, in order to bench LRANGE) ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 199.88% <= 1 milliseconds
100.00% <= 1 milliseconds
71428.57 requests per second====== LRANGE (first 100 elements) ======
  10000 requests completed in 0.31 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 10.11% <= 1 milliseconds
97.22% <= 2 milliseconds
100.00% <= 2 milliseconds
32573.29 requests per second====== LRANGE (first 300 elements) ======
  10000 requests completed in 0.62 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 10.02% <= 1 milliseconds
0.53% <= 2 milliseconds
70.06% <= 3 milliseconds
82.38% <= 4 milliseconds
99.86% <= 5 milliseconds
100.00% <= 5 milliseconds
16025.64 requests per second====== LRANGE (first 450 elements) ======
  10000 requests completed in 0.85 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 10.02% <= 2 milliseconds
2.29% <= 3 milliseconds
42.78% <= 4 milliseconds
87.31% <= 5 milliseconds
100.00% <= 5 milliseconds
11820.33 requests per second====== LRANGE (first 600 elements) ======
  10000 requests completed in 1.07 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 10.01% <= 1 milliseconds
0.03% <= 2 milliseconds
0.69% <= 3 milliseconds
10.58% <= 4 milliseconds
17.95% <= 5 milliseconds
100.00% <= 5 milliseconds
9319.66 requests per second很明显redis暂时不会成为瓶颈，那短板效应的话，其实每秒可以处理3800个请求的样子，短连接聊天室，每秒可以有3800个人在说话，应该暂时够用了吧？

Answer 15

http的keep live属性，它虽然有超时时间，但是的生命周期并不是严格按照超时时间来处理的。而且你在浏览器端无法像socket那样得到一个连接句柄。所以我能想到的就是使用ajax拉数据，但是这样会造成大量的http请求，服务器很快就会被拖垮。

Answer 16

现在html5有websocket接口，这样就可以维持一个socket连接，对于ie6（或者其他不支持websocket的浏览器）来说，可以使用flash来建立一个socket连接。

Answer 17

flash长连接的话可以保证用户实时获取消息，如果是短连接的话，需要做轮询，服务端压力取决于论询频率；异步websever的单机瓶颈应该是并发连接数，而不是cpu和内存，所以搞个16核cpu的机器，不如搞5台双核的机器来的潇洒，哈哈；对于聊天记录这种大文件，适合用nosql数据库，听说mongodb持久化还不错，redis的持久化做的好像还不是太好，速度还是很牛叉的；消息的推确实是个问题，如果采用短连接轮训，就可以避免推操作，但是有消息的实时性问题，总之，人多就有问题，当然如果真的人多的话就有钱买机器了，横向可扩展才是王道（个人想法勿喷，本人菜鸟一枚）