直播活动流架构

发布于 10-09 10:35 字数 462 浏览 4 评论 0原文

我之前已经发布过类似的问题,但我想知道使活动源实时工作的底层技术是什么?我正在将其设计为 100% 由 MySQL 数据库驱动,但遇到的问题是有 200 多个活动需要流式传输,并且有不同类型的流 + 需要支持至少 500,000 个并发用户。有基于地理的流、网络流、朋友流、业务流等。所有流数据都是根据我网站上的活动自行托管的。我的平台是Linux、MySQL、PHP。

面临的问题: 1)不确定如何解决这个问题。我应该在 AJAX、PHP 和 MySQL 中执行此操作,还是通过 RSS/XML 执行此操作,还是需要使用从文本文件读取的旧方式? 2) 流如何实时更新 - 将客户端活动存储在 cookie 或会话中、服务器到客户端推送、客户端到服务器拉取等? 3)是否与服务器更相关,例如假设我需要支持 500,000 个并发用户,我是否需要专门的服务器来执行此操作? 4)如果我需要为此使用专门的框架,有没有开源框架?

任何指向示例架构/实施策略或资源的链接都会有所帮助。

I have posted earlier on a similar question but I would like to know what is the underlying technology to make an activity feed work in real-time? I am designing it 100% database-driven in MySQL but running into issues are there are 200+ activities to stream out and there are different types of streams + need to support at least 500,000 concurrent users to start with. There are geographic-based streams, network streams, friend streams, business steams, etc. All stream data is self-hosted based on activities on my site. My platform is Linux, MySQL, PHP.

Issues facing:
1) Unsure about what way to approach this. Should I just do it in AJAX, PHP, and MySQL or is this done via RSS/XML or do I need to use old fashion read from text files?
2) How does the stream update in real-time - store activities client-side in a cookie or session, server to client push, client to server pull, etc?
3) Is it more server related like do I need a specialized server just to do this, assuming I need to support 500,000 concurrent users?
4) If I need to use specialized frameworks for this are there any open-source frameworks?

Any links to sample architecture/implementation strategies or resources would be helpful.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

苄①跕圉湢2024-10-16 10:35:37

我不知道“活动流”具体是什么意思;我以前没有做过类似的事情,但这就是我的想法:

  • 为 50K 用户提供服务可能意味着多个服务器 - 所以你不能使用或做任何会引入服务器亲和力的事情(使用会话变量等)。
  • 您希望全面提高效率 - 尽量减少数据交换(无论是大小还是频率)。
  • 避免不必要的解析(例如:XML)或昂贵的操作;处理大字符串等。
  • 仔细记录,经常进行性能测试。您可能想从一些概念验证开始。
  • 使用内存:读写磁盘的成本很高,因此将数据分流到内存中并在那里处理;例如,在应用程序启动时,您可以将整个数据库(好吧,服务请求所需的所有表/数据)分流到内存中,这样您就不需要建立数据库每个请求的连接。这并不能阻止您对数据库进行异步写回(服务器死机并且丢失内存中的数据往往会很糟糕)。
  • 研究成熟的缓存技术。
  • 通过异步,你可以 - 你想要最少的瓶颈。

I've got no idea what you mean specifically by "activity stream"; and I haven't done anything like this before, but here's what I'd be thinking:

  • Serving 50K users is probably going to mean multiple servers - so you can't use or do anything that is going to introduce server affinity (using session variables, etc).
  • You want to be as efficient as you can across the board - minimal data exchanges (both in size and frequency).
  • Avoid unnecessary parsing (e.g: XML) or operations that are expensive; dealing with big strings, etc.
  • Document carefully, performance test often. You might want to start with some Proof of Concepts.
  • Use memory: reading and writing to disk is expensive, so shunt data into memory and deal with it there; for example, on application start-up, you might shunt the whole database (well, all the tables/data that you'll need to serve requests) into memory so you don't need to establish database connections for every request. This doesn't stop you from doing asynchronous write-backs to the database (having a server die and losing in-memory data tends to suck).
  • Investigate mature caching technologies.
  • By asynchronous where you can - you want minimal bottle-knecks.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文