"网易宝"是网易公司为方便用户进行网上交易推出的安全、稳定、快捷的在线支付平台，为用户提供了多种方便的在线充值、交易管理、在线支付帐户管理、代收、提现等服务。网易宝现更名为网易支付。
 

网易宝有限公司是网易旗下的第三方支付公司。依托网易邮箱、游戏、门户网站等强势产品优势，致力于构建具有网易特色的综合支付平台，为企业和用户提供"安全、便捷、人性化"的在线支付解决方案。

业务覆盖:B2C、B2B、C2B2C; 服务线上线下产品，包括网络游戏、电子商务、在线教育、生活缴费、保险行业、彩票行业。

网易宝支撑了整个集团业务绝大部分的支付场景，平均每天的支付订单有100万单，接近1亿的交易额。因此，一个严谨实用的系统是必不可少的，下面就从我的理解上说说网易宝的系统是如何实现高可用的。
 

网易宝的所有核心应用和中间件都是集群部署的，通过负载均衡，平均分配流量。

对于业务系统， 在nginx服务器(nginx集群部署，负载均衡使用LVS)上配置了负载均衡策略，路由请求到后端的应用服务器resin。如果web应用集群某台机器挂了，nginx通过心跳健康检查，3秒内能检测到，把这台机器从可用列表中剔除出去。

中间件dubbo的consumer基于负载均衡算法， 获取zookeeper上统计的provider的负载情况，决定请求哪台provider。Kafka也是类似的原理。如果dubbo服务的某台provider挂了，与provider维持长连接的zookeeper心跳线程会检测到，把provider从服务的可用provider列表中剔除，并快速通知到所有依赖该服务的consumer(也是维持的TCP长连接)，consumer更新本地缓存的provider列表。

对于有状态的服务器，都有数据备份机制。

数据库主库会异步同步数据到备库。数据库主库挂了，如果切到备库，可能会丢失部分业务数据(异步复制，网络稳定情况下10ms以内的延迟，不是同步写多份的)。Kafka每条消息都会复制到不同的机器(broker)上。Zookeeper上的数据也是多写的。Kafka的主broker挂了或者zookeeper的主服务器挂了，通过选举算法选举出新的leader。Leader用于读写，slavers用于备份。Leader挂了，从slavers中选举出新的leader快速恢复服务。Kafka和zookeeper是做了数据高可靠性保证的，极小概率会出现丢失数据的情况。
 

多机房部署上，网易宝有杭州、北京两地机房。杭州是主机房，北京是备，不是多活的。 北京的机房服务器数量较少，数据库服务器性能较差，数据复制也有秒级的延迟。所以不到万不得已，是不会切到备用机房的。目前网易支付已经在搭建义桥的机房，2017年实现滨江机房和义桥机房的双活,解决机房的单点问题。

综上所述，在同一个机房，网易宝无论是无状态的服务器，还是有状态的服务器，从存储层，到中间件层，到应用层，都不存在单点问题。机房的单点问题也会在不久后解决。

更新不频繁的基础热点数据，如配置项、所有商户信息、网关数据，在应用启动时，加载到本地缓存。减少对数据库的频繁调用。

网易宝的session管理使用中心化的memcached集群，业务流程中的一些状态数据，也是存放到memcached。系统之间使用文件数据交互的，文件保存到FTP。需要持久化的业务数据保存到中心化的数据库。 不管是业务数据，还是非业务数据，都不会保存到本地应用服务器，保证应用无状态化，使得应用集群可以快速的横向扩展。

为了保证核心支付服务的稳定性，数据库上做了读写分离。核心业务的读写走主库。对于读实时性要求不高的查询场景，查询备库。如商户系统订单的查询请求。对于耗时长的sql的查询场景，查询异构库，如商户的对账单下载。

§

§ 热点账户处理异步化

为了避免热点账户上的行锁的激烈竞争影响系统吞吐，网易宝对热点账户的余额更新和资金流水生成，做了异步处理。业务完成后如果需要变动热点账户的金额，先生成缓冲流水，然后由调度任务异步去消费缓冲流水去更新余额、生成资金流水。使热点账户的并发锁竞争变成了串行处理，大大降低了行锁竞争导致的线程阻塞，提高了系统的吞吐。

提现、退款处理对实时性的要求不高，通过异步化，对于处理失败的订单可以用重试机制补偿。避免了同步调用失败给用户不好的体验。