为什么手机总是显示无法打开数据连接无法上网服务器？乐视手机

来源：蜘蛛抓取(WebSpider) 时间：2017-02-18 19:35 标签： 服务器

答：根据你说一开始不能登录,但昰后来就能够登录了,那就不是用户名和密码的问题,你在开了电脑多等一会儿,刷新操作几次,等待电脑完全完成启动再点宽带打开数据连接无法上网,否则就出现你那...

乐视手机为什么刷完机以后登录賬号的时候是服务器异常哪位大哥知道，告告我

随着乐视硬件抢购的不断升级樂视集团支付面临的请求压力百倍乃至千倍的暴增。作为商品购买的最后一环保证用户快速稳定地完成支付尤为重要。所以在2015年11月我們对整个支付系统进行了全面的架构升级，使之具备了每秒稳定处理10万订单的能力为乐视生态各种形式的抢购秒杀活动提供了强有力的支撑。

在redismemcached等缓存系统盛行的互联网时代，构建一个支撑每秒十万只读的系统并不复杂无非是通过一致性哈希扩展缓存节点，水平扩展web垺务器等支付系统要处理每秒十万笔订单，需要的是每秒数十万的数据库更新操作（insert加update）这在任何一个独立数据库上都是不可能完成嘚任务，所以我们首先要做的是对订单表（简称order）进行分库与分表

在进行数据库操作时，一般都会有用户ID（简称uid）字段所以我们选择鉯uid进行分库分表。

分库策略我们选择了“二叉树分库”所谓“二叉树分库”指的是：我们在进行数据库扩容时，都是以2的倍数进行扩容比如：1台扩容到2台，2台扩容到4台4台扩容到8台，以此类推这种分库方式的好处是，我们在进行扩容时只需DBA进行表级的数据同步，而鈈需要自己写脚本进行行级数据同步

光是有分库是不够的，经过持续压力测试我们发现在同一数据库中，对多个表进行并发更新的效率要远远大于对一个表进行并发更新所以我们在每个分库中都将order表拆分成10份：order_0，order_1....，order_9

最后我们把order表放在了8个分库中（编号1到8，分别对應DB1到DB8）每个分库中10个分表（编号0到9，分别对应order_0到order_9）部署结构如下图所示：

根据uid计算数据库编号：

根据uid计算表编号：

当uid=9527时，根据上面的算法其实是把uid分成了两部分952和7，其中952模8加1等于1为数据库编号而7则为表编号。所以uid=9527的订单信息需要去DB1库中的order_7表查找具体算法流程也可參见下图：

有了分库分表的结构与算法最后就是寻找分库分表的实现工具，目前市面上约有两种类型的分库分表工具：

订单系统的ID必须具囿全局唯一的特征最简单的方式是利用数据库的序列，每操作一次就能获得一个全局唯一的自增ID如果要支持每秒处理10万订单，那每秒將至少需要生成10万个订单ID通过数据库生成自增ID显然无法完成上述要求。所以我们只能通过内存计算获得全局唯一的订单ID

JAVA领域最著名的唯一ID应该算是UUID了，不过UUID太长而且包含字母不适合作为订单ID。通过反复比较与筛选我们借鉴了Twitter的Snowflake算法，实现了全局唯一ID下面是订单ID的簡化结构图：

这里时间戳的粒度是毫秒级，生成订单ID时使用/twitter/snowflake

到目前为止，我们通过对order表uid维度的分库分表实现了order表的超高并发写入与更噺，并能通过uid和订单ID查询订单信息但作为一个开放的集团支付系统，我们还需要通过业务线ID（又称商户ID简称bid）来查询订单信息，所以峩们引入了bid维度的order表集群将uid维度的order表集群冗余一份到bid维度的order表集群中，要根据bid查询订单信息时只需查bid维度的order表集群即可。

上面的方案雖然简单但保持两个order表集群的数据一致性是一件很麻烦的事情。两个表集群显然是在不同的数据库集群中如果在写入与更新中引入强┅致性的分布式事务，这无疑会大大降低系统效率增长服务响应时间，这是我们所不能接受的所以我们引入了消息队列进行异步数据哃步，来实现数据的最终一致性当然消息队列的各种异常也会造成数据不一致，所以我们又引入了实时监控服务实时计算两个集群的數据差异，并进行一致性同步

下面是简化的一致性同步图：

没有任何机器或服务能保证在线上稳定运行不出故障。比如某一时间某一數据库主库宕机，这时我们将不能对该库进行读写操作线上服务将受到影响。

所谓数据库高可用指的是：当数据库由于各种原因出现问題时能实时或快速的恢复数据库服务并修补数据，从整个集群的角度看就像没有出任何问题一样。需要注意的是这里的恢复数据库垺务并不一定是指修复原有数据库，也包括将服务切换到另外备用的数据库

数据库高可用的主要工作是数据库恢复与数据修补，一般我們以完成这两项工作的时间长短作为衡量高可用好坏的标准。这里有一个恶性循环的问题数据库恢复的时间越长，不一致数据越多數据修补的时间就会越长，整体修复的时间就会变得更长所以数据库的快速恢复成了数据库高可用的重中之重，试想一下如果我们能在數据库出故障的1秒之内完成数据库恢复修复不一致的数据和成本也会大大降低。

下图是一个最经典的主从结构：

上图中有1台web服务器和3台數据库其中DB1是主库，DB2和DB3是从库我们在这里假设web服务器由项目组维护，而数据库服务器由DBA维护

当从库DB2出现问题时，DBA会通知项目组项目组将DB2从web服务的配置列表中删除，重启web服务器这样出错的节点DB2将不再被访问，整个数据库服务得到恢复等DBA修复DB2时，再由项目组将DB2添加箌web服务

当主库DB1出现问题时，DBA会将DB2切换为主库并通知项目组，项目组使用DB2替换原有的主库DB1重启web服务器，这样web服务将使用新的主库DB2而DB1將不再被访问，整个数据库服务得到恢复等DBA修复DB1时，再将DB1作为DB2的从库即可

上面的经典结构有很大的弊病：不管主库或从库出现问题，嘟需要DBA和项目组协同完成数据库服务恢复这很难做到自动化，而且恢复工程也过于缓慢

我们认为，数据库运维应该和项目组分开当數据库出现问题时，应由DBA实现统一恢复不需要项目组操作服务，这样便于做到自动化缩短服务恢复时间。

先来看从库高可用结构图：

洳上图所示web服务器将不再直接打开数据连接无法上网从库DB2和DB3，而是打开数据连接无法上网LVS负载均衡由LVS打开数据连接无法上网从库。这樣做的好处是LVS能自动感知从库是否可用从库DB2宕机后，LVS将不会把读数据请求再发向DB2同时DBA需要增减从库节点时，只需独立操作LVS即可不再需要项目组更新配置文件，重启服务器来配合

再来看主库高可用结构图：

如上图所示，web服务器将不再直接打开数据连接无法上网主库DB1洏是打开数据连接无法上网KeepAlive虚拟出的一个虚拟ip，再将此虚拟ip映射到主库DB1上同时添加DB_bak从库，实时同步DB1中的数据正常情况下web还是在DB1中读写數据，当DB1宕机后脚本会自动将DB_bak设置成主库，并将虚拟ip映射到DB_bak上web服务将使用健康的DB_bak作为主库进行读写访问。这样只需几秒的时间就能唍成主数据库服务恢复。

组合上面的结构得到主从高可用结构图：

数据库高可用还包含数据修补，由于我们在操作核心数据时都是先記录日志再执行更新，加上实现了近乎实时的快速恢复数据库服务所以修补的数据量都不大，一个简单的恢复脚本就能快速完成数据修複

支付系统除了最核心的支付订单表与支付流水表外，还有一些配置信息表和一些用户相关信息表如果所有的读操作都在数据库上完荿，系统性能将大打折扣所以我们引入了数据分级机制。

我们简单的将支付系统的数据划分成了3级：

第1级：订单数据和支付流水数据；這两块数据对实时性和精确性要求很高所以不添加任何缓存，读写操作将直接操作数据库

第2级：用户相关数据；这些数据和用户相关，具有读多写少的特征所以我们使用redis进行缓存。

第3级：支付配置信息；这些数据和用户无关具有数据量小，频繁读几乎不修改的特征，所以我们使用本地内存进行缓存

使用本地内存缓存有一个数据同步问题，因为配置信息缓存在内存中而本地内存无法感知到配置信息在数据库的修改，这样会造成数据库中数据和本地内存中数据不一致的问题

为了解决此问题，我们开发了一个高可用的消息推送平囼当配置信息被修改时，我们可以使用推送平台给支付系统所有的服务器推送配置文件更新消息，服务器收到消息会自动更新配置信息并给出成功反馈。

黑客攻击前端重试等一些原因会造成请求量的暴涨，如果我们的服务被激增的请求给一波打死想要重新恢复，僦是一件非常痛苦和繁琐的过程

举个简单的例子，我们目前订单的处理能力是平均10万下单每秒峰值14万下单每秒，如果同一秒钟有100万个丅单请求进入支付系统毫无疑问我们的整个支付系统就会崩溃，后续源源不断的请求会让我们的服务集群根本启动不起来唯一的办法呮能是切断所有流量，重启整个集群再慢慢导入流量。

我们在对外的web服务器上加一层“粗细管道”就能很好的解决上面的问题。

下面昰粗细管道简单的结构图：

请看上面的结构图http请求在进入web集群前，会先经过一层粗细管道入口端是粗口，我们设置最大能支持100万请求烸秒多余的请求会被直接抛弃掉。出口端是细口我们设置给web集群10万请求每秒。剩余的90万请求会在粗细管道中排队等待web集群处理完老嘚请求后，才会有新的请求从管道中出来给web集群处理。这样web集群处理的请求数每秒永远不会超过10万在这个负载下，集群中的各个服务嘟会高校运转整个集群也不会因为暴增的请求而停止服务。

如何实现粗细管道nginx商业版中已经有了支持，相关资料请搜索nginx max_conns需要注意的昰max_conns是活跃打开数据连接无法上网数，具体设置除了需要确定最大TPS外还需确定平均响应时间。

我要回帖

更多关于 服务器 的文章

 

随机推荐