im大型分布式实时计费服务器系统架构2.0

整个创业团队后台就我一个设计,架构,和开发.一路上很辛苦,因为遇到的问题很多很多,并不是想象的那么简单.本来2.0想用go语言开发的,简单,又快,又支持热更新.处理速度和c++差不多,但灵活度没有c++高,没有那么多特性.设计一个复杂的Im系统,有点不合适.然后我又用回了c++,本人还是热衷于c++,我使用很多语言,都没有c++的灵活,好用.

感觉qt的类库非常强大,还有它的机制,非常容易扩展,所以还是继续qt+epoll模型.

我重新设计了以前1.0服务器不足之处,整个服务器性能提升到将近20倍左右,并支持动态扩容,容易维护和升级.能够分布到全球不同地方,包扣一套运维系统的架构,能够实现方便的管理.

我们服务器系统业务逻辑非常复杂,超过了腾讯的业务逻辑,对于一般的IM软件只需要发送消息到目标客户端就可以了,而我们这套系统需要对视频时间和每条消息进行实时计费,如果接受者无法在这段时间内回复消息就得重新转发到其他客户端,一直到此条消息有人回复或者生命周期结束.并且支持消息类型的过滤,消息发送的算法优化.保证数据的安全性和计费的准确性,所有计算全部都是由服务器来承担的

客户端能够支持消息预约,消息条件的过滤,消息的生命周期,当前用户的状态.离线消息,推送消息,电子邮件的通知,数据的校验,充值的反馈

,快速拉取个人信息和记录.

1.增加了数据同步服务器,在整个集群里面只存在一个用户实例,个人数据信息的实时同步.

2.数据库采用redits+msyql集群组合,从以前单台数据库处理速度升级到 4000+/s升级到70000+/s

3.离线消息系统独立,离线消息系统从以前和业务服务器分离开来了,成为一条独立的系统和apns推送集群衔接在一起了,这样能够更加快速进行离线推送到用户移动端上.

4.独立的apns轮询推送集群,对于移动端用户来说,大多数用户都是待机状态,当每秒要推送上千或者上万,单台apns推送服务器根本就没法支撑,所以设计了apns轮询推送机制,能够减轻服务器的负载,并且快速进行推送

5.充值服务器实时响应,服务器不停的会对大量用户进行实时计费,考虑到大量充值事件响应,独立到一台服务器上,paypal的ipns通知事件,能够立刻更新当前用户的账户金额.

6.状态监测服务器,能够监测当前业务服务器的负载状态,并实时更新和发送到负载最小的业务服务器给客户端登陆

7.数据验证服务器,对用户登入信息进行验证,并通知到需要的登入的业务服务器,防止用户非法登入.

8.消息管理服务器,对消息转发到几十个相应的接收者上,生命周期的计算,消息的计费,视频消息的实时计费,无人响应的转发规则,预约消息的转发规则

9.后台服务器管理端,能否对不同类型的服务端进行配置和设定,每条服务端日志的记录.

10.web后台管理系统的设计,对用户的信息进行管理和操作.金额的统计,资金流的发放.

11.当然也有一套强大监控系统,服务端监控和服务器监控平台,服务器监控平台用的是监控宝,服务端用的自己开发的.

服务器架构图:

时间: 2024-10-10 10:44:25

im大型分布式实时计费服务器系统架构2.0的相关文章

大型分布式电商系统架构是如何从0开始演进的?【转】

本文是学习大型分布式网站架构的技术总结.对架构一个高性能.高可用.可伸缩及可扩展的分布式网站进行了概要性描述,并给出一个架构参考.文中一部分为读书笔记,一部分是个人经验总结,对大型分布式网站架构有较好的参考价值. 一.大型分布式网站架构技术 1.大型网站的特点 用户多,分布广泛 大流量,高并发 海量数据,服务高可用 安全环境恶劣,易受网络攻击 功能多,变更快,频繁发布 从小到大,渐进发展 以用户为中心 免费服务,付费体验 2.大型网站架构目标 高性能:提供快速的访问体验. 高可用:网站服务一直可

大型分布式电商系统架构有哪些

1.大型网站的特点 用户多,分布广泛 大流量,高并发 海量数据,服务高可用 安全环境恶劣,易受网络攻击 功能多,变更快,频繁发布 从小到大,渐进发展 以用户为中心 免费服务,付费体验 2.大型网站架构目标 高性能:提供快速的访问体验. 高可用:网站服务一直可以正常访问. 可伸缩:通过硬件增加/减少,提高/降低处理能力. 安全性:提供网站安全访问和数据加密.安全存储等策略. 扩展性:方便地通过新增/移除方式,增加/减少新的功能/模块. 敏捷性:随需应变,快速响应: 3.大型网站架构模式 分层:一般

浅谈大型网站动态应用系统架构【转】

浅谈大型网站动态应用系统架构 动态应用,是相对于网站静态内容而言,是指以c/c++.php.Java.perl..net等服务器端语言开发的网络应用软件,比如论坛.网络相册.交友.BLOG等常见应用.动态应用系统通常与数据库系统.缓存系统.分布式存储系统等密不可分. 大型动态应用系统平台主要是针对于大流量.高并发网站建立的底层系统架构.大型网站的运行需要一个可靠.安全.可扩展.易维护的应用系统平台做为支撑,以保证网站应用的平稳运行. 大型动态应用系统又可分为几个子系统: l l l l l l

机票实时搜索系统架构设计

机票实时搜索系统架构设计 ? 不同的业务场景,不同的特征 ? 结合特征去进?设计和优化 ? 通?!=最优 ? 量体裁? 分布式系统的CAP理论 首先把分布式系统中的三个特性进行了如下归纳:    ● 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值.(等同于所有节点访问同一份最新的数据副本) ● 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求.(对数据更新具备高可用性) ● 分区容错性(P):以实际效果而言,分区相当于对通信的时限要求.系统如果不能

大型高性能ASP.NET系统架构设计

大型动态应用系统平台主要是针对于大流量.高并发网站建立的底层系统架构.大型网站的运行需要一个可靠.安全.可扩展.易维护的应用系统平台做为支撑,以保证网站应用的平稳运行. 大型动态应用系统又可分为几个子系统: Web前端系统 负载均衡系统 数据库集群系统 缓存系统 分布式存储系统 分布式服务器管理系统 代码分发系统 Web前端系统 为了达到不同应用的服务器共享.避免单点故障.集中管理.统一配置等目的,不以应用划分服务器,而是将所有服务器做统一使用,每台服务器都可以对多个应用提供服务,当某些应用访问

分布式实时日志系统(一)环境搭建之 Jstorm 集群搭建过程/Jstorm集群一键安装部署

最近公司业务数据量越来越大,以前的基于消息队列的日志系统越来越难以满足目前的业务量,表现为消息积压,日志延迟,日志存储日期过短,所以,我们开始着手要重新设计这块,业界已经有了比较成熟的流程,即基于流式处理,采用 flume 收集日志,发送到 kafka 队列做缓冲,storm 分布式实时框架进行消费处理,短期数据落地到 hbase.mongo中,长期数据进入 hadoop 中存储. 接下来打算将这其间所遇到的问题.学习到的知识记录整理下,作为备忘,作为分享,带给需要的人. 淘宝开源了许多产品组件

分布式实时日志系统(二) 环境搭建之 flume 集群搭建/flume ng资料

最近公司业务数据量越来越大,以前的基于消息队列的日志系统越来越难以满足目前的业务量,表现为消息积压,日志延迟,日志存储日期过短,所以,我们开始着手要重新设计这块,业界已经有了比较成熟的流程,即基于流式处理,采用 flume 收集日志,发送到 kafka 队列做缓冲,storm 分布式实时框架进行消费处理,短期数据落地到 hbase.mongo中,长期数据进入 hadoop 中存储. 接下来打算将这其间所遇到的问题.学习到的知识记录整理下,作为备忘,作为分享,带给需要的人. 学习flume ng的

分布式实时日志系统(四) 环境搭建之centos 6.4下hbase 1.0.1 分布式集群搭建

一.hbase简介 HBase是一个开源的非关系型分布式数据库(NoSQL),它参考了谷歌的BigTable建模,实现的编程语言为 Java.它是Apache软件基金会的Hadoop项目的一部分,运行于HDFS文件系统之上,为 Hadoop 提供类似于BigTable 规模的服务.因此,它可以容错地存储海量稀疏的数据.HBase在列上实现了BigTable论文提到的压缩算法.内存操作和布隆过滤器.HBase的表能够作为MapReduce任务的输入和输出,可以通过Java API来存取数据,也可以

大型网站系统架构分析

千万级的注册用户,千万级的帖子,nTB级的附件,还有巨大的日访问量,大型网站采用什么系统架构保证性能和稳定性? 首先讨论一下大型网站需要注意和考虑的问题. 数据库海量数据处理:负载量不大的情况下select.delete和update是响应很迅速的,最多加几个索引就可以搞定,但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题.另外在高UPDATE的情况下,更新一个聚焦索引的时间基本上是不可忍受的.索引和更新是一对天生的冤家. 高并发死锁:平时我们感觉不到,但数据库死锁在高并发的