微服务中的逻辑复杂处理时间长的情况，在高并发量下，导致服务线程消耗尽，不能再创建线程处理请求。对这种情况的优化，除了在程序上不断调优(数据库调优，算法调优，缓存等等)，可以考虑在架构上做些调整，先返回结果给客户端，让用户可以继续使用客户端的其他操作，再把服务端的复杂逻辑处理模块做异步化处理。这种异步化处理的方式适合于客户端对处理结果不敏感不要求实时的情况，比如群发邮件、群发消息等。下面介绍三种

某个大型互联网系统中，产品经理提了一个需求，需要上线一个新功能点，运营人员在运营系统中配置哪些用户具有这个新功能，不在配置名单里的用户不具备这个功能，名单的数量约为几千个。运营系统是web系统，部署在南方c城市的web机房用户端是pc客户端软件，日均DAU几百万，每秒TPS十几万，客户端和后台服务进程是通过socket通信，后台服务进程部署在南方和北方各一个机房。 运营系统和数据库

选主进程的方式有很多，完善点的方案就是zookeeper来做。这里介绍的是一种基于redis选主的方案，快速开发，快速实现。Springside4里有个MasterElector类，细读代码后整理出自己的总结如下。1.      业务进程启动时生成hostId，hostId的规则是“主机名-随机数”，一台主机部署多个进程实例的情况，也可以改为“主机名-端口”。2.      业务进程调

A进程是提供接口给手机客户端调用，B进程是刚上的服务，A进程调用B进程的超时时间设置为3秒，超过3秒就报错，上报到监控系统。上线后收到短信告警，超时的请求量较多。查看监控图如下纵座标的顶部是3秒，每隔一小时就有一个高峰达到3秒。刚开始怀疑B进程有定时任务在跑，查看代码后发现没有，最后查到运维人员在系统中跑定时任务，每小时检查log目录下的文件是否大于500M，是的话就切割文件压缩。文件

参考资料：比原链DAPP开发流程储蓄分红合约Demo访问地址储蓄分红合约后端bufferserver源码储蓄分红合约前端源代码储蓄分红合约详细说明equity智能合约学习文档插件钱包API简介​ 这章的内容详细分析一下涉及智能合约Dapp的整个开发流程，注意是涉及只能合约，如果你只要一些基本转BTM功能没有太大意义，本内容补充一下官方提供的比原链DAPP开...

很多直播平台，会录制一些大主播的内容或者精彩内容，提供回放给用户观看。音视频的录制是在云端合成录制成个文件，有比较成熟的技术支持。技术的复杂性在于录制弹幕，礼物特效，进出场人数等流水。在直播时，弹幕、礼物特效、观看人数的变化都是通过广播消息包推送到客户端，流水录制服务器以摸拟客户端的方式接收广播消息包存放在数据库，数据库中需要保存消息的时间戳和广播包的内容。流水录制服务器同时也去拉取直播时的礼

网上有很多介绍秒杀系统架构文章，写得不错，包括前后端的实现，这里只从后台服务系统架构阐述。打开页面时查询商品数量和点击抢购按钮提交校验时都是从本地web进程内缓存读取，这里没有使用redis，是考虑到redis号称单机qps最大10w/s，用户端可能会使用些作弊器产生的qps大于10w/s,所以通过web进程内缓存实现，web进程可以通过nginx做平行扩容。单个web应用可支持的

# 简介​ 本章内容会针对比原官方提供的dapp-demo，分析里面的前端源码，分析清楚整个demo的流程，然后针对里面开发过程遇到的坑，添加一下个人的见解还有解决的方案。### 储蓄分红合约简述为了方便理解，这里简单说说储蓄分红合约的内容，具体可以查看[储蓄分红合约详细说明](https://github.com/oysheng/bufferserver/blob/master...