剑指BAT

企业级别项目实战之《迷你微信红包》

2017-12-28  本文已影响637人  batbattle

项目名称:迷你红包

功能:注册、登陆、添加好友/群、收发红包、红包过期自动退还、离线消息持久化、消息确认;

扩展功能:支持表情、语音、视频等富媒体聊天。

技术难点:千万级别好友、群关系的数据库(表)设计;百万级别高并发设计与实现;消息订阅与发布;单聊、群聊;应用层消息确认机制实现;亿级别数量里寻找下一秒需过期红包;

核心技术:加密算法(RSA/MD5/DES/ECC)、多线程编程及同步机制(读写锁/CAS)、IO复用函数、零拷贝;MySQL、红包随机算法、红包过期处理算法、应用层亿级别消息确认机制;


第一章   项目背景和需求

带着大家了解项目功能点,功能模块组织等。通过注册和登陆的核心流程分析,让大家学会如何细分一个功能的具体实现,以及在企业里面实现一个功能点,又要考虑和注意哪些问题等。

第二章  好友&群表设计及优化

结合MySQL的三大范式,反范式、一对多、多对多等设计;

海量数据场景的数据缓存机制及同步更新分析;

腾讯是如何处理微信8.7亿用户(分库分表、主从复制、主主复制、两地三中心)?;

第三章  分析多种应用层消息如何做确认

TCP提供可靠的数据传输协议,但是她只保障应用层交付给她的“数据”可靠传送到endpoint,但是我们依然需要实现应用层数据确认机制。

当我用微信发消息给“王思聪”时,他明明都已经回复我了,但是微信偶尔也会提示“消息未发送成功”。

在本章节里,带着大家一起分析以下内容:

1.为何还需应用层做数据确认?

2.为何微信会发出错误提示?

3.我们该怎么做到应用层数据确认?

4.消息已读回执如何实现?

5.海量消息又该如何完美处理?

第四章  如何处理百亿级别红包“秒级别”过期

估计目前微信的红包数量在数百亿量级,那么为了达到精确的“秒级别”过期,我们又该如何去设计和实施呢?

我从以下几点带着大家去分析:

1.Linux 的定时任务crontab机制和思想

2.分布式海量数据如何查找?

3.如何防止“写热点”?

4.百亿红包过期如何实现?

第五章  消息订阅与发布

群聊,是一个大家都熟悉的功能。那么拥有8.7亿用户的微信产品又该如何实现群聊呢?

我从以下几点带着大家去分析:

1.群聊常规实现机制有哪些、缺点是什么?

2.消息订阅与发布的概念以及核心实现思想

3.写扩散or读扩散?

第六章  单台服务器百万级别高并发设计与实现

通过前面内容讲解,最后一起攻克最后一个核心难点“单台百万”高并发设计与实现。

我从以下几点带着大家去分析:

1.进程模型的选择(多线程/线程池、多进程/进程池、绿色线程?IO/CPU Bound分析)

2.网络模型的选择(阻塞+线程池、IO复用Select/Poll/Epoll)

3.设计模式的选择(半同步/半异步、领导者/追随者)

4.核心数据结构选择


上面六个章节内容,也就覆盖了我们在企业里从立项后的项目功能梳理,实现分析,到具体技术选型的全过程。后面有机会,给大家介绍在企业里如何进行大规模压力测试。

还需要了解更多,可点击 课程视频

上一篇下一篇

猜你喜欢

热点阅读