webster-wq
commented
4 years ago 1.首先，基于这个项目淘票票跟口碑给出的需求是能够支撑100万的并发量。为此我们首先开发了一套基于socket的答题游戏，但是测试同学经过压力测试给出的结果是当并发达到100时会出现大面积丢包和断连的情况。为了解决这个问题，当时有两种方案，第一种方案是增加服务器配置和数量，第二种是优化代码或者寻找更好的解决方案。而第一种方案无疑会增加成本，为此团队经过充分调研之后发现mqtt适用于网络代价昂贵，带宽低，以及不可靠网络环境的特点可以完美解决我们项目中遇到的问题，为此我们引入了mqtt，又开发了第二个版本，经过压测，我们的项目在并发量达到100万时非常稳定。丢包和掉线率趋近于0。mqtt是基于pub/sub模式服务器发布一个topic，客户端通过clinetId订阅topic从而建立长链接。websocket是客户端直接跟服务端建立长链接，mqtt协议应该是在websocket基础上进行了封装。 2.首先在用户进入房间以后在mqtt的connect阶段我进行了一次异常捕获。如果出现异常我会把它认为版本较老的手机的客户端对mqtt不支持或者其他未知场景的异常。这时候程序会向服务器发起定时轮训，间隔是1秒。确保用户能够正常参与答题。其次在用户能够与服务端建立长链接的情况下，我们会对用户断连或者error的场景进行监听，发现用户断链或者error。我们会发起重连并且同时开启轮询，轮询的间隔为一秒钟；重连的机制是初次重连的延时是1秒钟，之后的每次尝试重连延时都会加倍，直到达到20秒的上限，之后的每一次重连都会保持的20秒钟，直到连接恢复然后停止轮询（*一场答题游戏的时间是1分40秒，共7题，答题时间10秒等待下一题时间5秒，其中包括4道百科题，和三道赛场预判题，百科题会在十秒答题时间结束之后公布答案，预判题会在答题结束之后公布答案，基于游戏时间的考虑以及重连时间加倍的规则最终确定了与15秒钟最为接近的20秒） 3.掉链率统计是在用户异常 断连 以及连接的行为进行埋点 采用的公式是 (异常数量 + 断连数量) / 连接数量 4.样式处理： 字体采用了设计师提供的: Helvetica Neue,Helvetica,PingFang SC,Hiragino Sans GB,Microsoft YaHei,SimSun,sans-serif保证不同语言的字体表现差异最小; 其他样式样式有两种方案: 方案一: 对于每种语言书写一套兼容的样式，此种方案工作量较大没有采用 方案二: 对于弹层卡片，弹层卡片的文案较为固定，所以由产品经理出面协调对卡片的每个区域的文案进行了长度限制。 对于答题卡，答题卡的内容不固定，所有题目都是从题库抽取。我对题目进行了高度自适应。对于答按选项由于样式固定文案不固定，所以我对按钮设置了溢出隐藏不换行的操作，同时对包裹文本的标签进行了offsetWidth的判断如果文本容器的长度大于按钮长度就对其增加css3属性通过animation增加文本的滚动动画
问题列表：