网站建设的关键技术优化点

大流量抄表系统的设计方法,当这些方法用尽后,如何处理仍然产生的大流量?因此,扣球系统必须解决以下几个关键问题。1Java处理大型并发动态请求的优化问题。与一般的web服务器(Ngi…

大流量抄表系统的设计方法,当这些方法用尽后,如何处理仍然产生的大流量?因此,扣球系统必须解决以下几个关键问题。1Java处理大型并发动态请求的优化问题。与一般的web服务器(Nginx或Apache)相比,Java在处理大并发HTP请求方面能力较弱,所以一般我们会静态地制作大流量的web系统,这种转换允许大部分请求和数据直接返回到NginxI服务器或web代理服务器(Varnish,squid,Java层只处理少量数据的动态请求。对于这些请求,可以使用以下优化方法:直接使用Servlet处理请求。避免使用传统的MVC框架,它可以绕过许多复杂和不太有用的处理逻辑,节省1毫秒的时间。它取决于对MVC框架的依赖程度;直接输出流数据。使用响应getoutputstreamo而不是resp.getWriter公司)可以节省一些不变的字符数据编码,提高性能;在数据输出时,建议使用JSON而不是模板引擎(通常解释和执行)输出页面。2同一产品同时阅读的问题有些读者可能认为这个问题很容易解决。这只不过是把热数据放入Tair缓存。为了保证命中率,集中式Tair缓存通常使用一致的哈希,因此同一个密钥将落在同一台机器上。虽然一台Tair缓存机每秒可以支持300000个请求,但它仍然远远不够处理大二级的热门产品。如何彻底解决单点瓶颈?答案是使用应用层Localcache,也就是说,与产品相关的数据缓存在spike系统的一台计算机上。那么如何缓存数据呢?答案是将其分为动态数据和静态数据,分别进行处理。库存等动态数据会在本机上以被动失效的方式缓存一定时间(通常是几秒钟),一直缓存到峰值结束,失效后再去Tai缓存拉取最新的数据。读者可能仍有疑问,如果数据不一致,频繁更新的数据(如库存)是否会导致超卖?这需要使用前面介绍的读取数据的分层验证原则。读取场景可以允许某些脏数据,因为这里的错误判断只会导致少数原始缺货订单请求被误认为是库存。您可以等到数据真正写入时才保证最终的一致性,通过高可用性和一致性的数据平衡来解决高并发数据读取的问题。三。同一数据的大并发更新问题Localcache的使用和数据的分层验证在一定程度上解决了大并发读的问题,但无论如何,大并发写的问题,如减少库存是无法避免的。这也是尖峰情景的核心技术难点。同样的数据必须存储在数据库的一行(MYSQL)中,因此会有大量线程争夺INNODB的行锁。并发度越高,等待的线程越多,TPS下降,RT上升,数据库吞吐量受到严重影响。这里会有一个问题,就是单一的热点商品会影响整个数据库的性能,我们不希望看到0.01%的商品影响9999商品。这里的解决方案也是遵循上面介绍的第一个原则,将热点产品“隔离”到一个单独的热点库中,尽管这会带来维护麻烦(对热点数据和单独的数据库进行动态迁移等),但是将热点项分离到单独的数据库中并不能解决并发锁定的问题。有两种方法可以解决并发锁问题。第一种是在应用层排队。根据产品维度设置队列顺序执行,可以降低同一台机器在数据库记录操作的同一行上的并发性,也可以控制单个产品占用的数据库连接数,防止热产品占用过多的数据库连接。第二种是在数据库层排队。应用层只能进行单机排队,但是应用层的机器很多,这种排队方式对并发的控制还是非常有限的。如果您可以在数据库层进行全局排队,这是非常理想的。数据库团队在MYSQL的INNODB层开发了一个补丁,可以在数据库层并发的对单行记录进行排队。你可能会有问题:你必须等待排队和锁定竞争吗?有什么区别?如果你熟悉MYSQL,你应该知道INNODB内部的死锁检测以及MYSQLServer和INNODB之间的切换会消耗更多的性能。MYSQL核心团队还做了很多其他方面的网站建设优化,比如COMMIT_-ON-u-SUCCESS和ROLLBACKONFAIL-patch,加上SQL中的提示,在交易中不需要等待应用层提交提交。数据执行完最后一条SQL后,根据TargetEffectRow或rollback的结果直接提交,可以减少网络的等待时间(平均约0.7毫秒)。

作者: guangdongseo

为您推荐

发表评论

电子邮件地址不会被公开。 必填项已用*标注

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

返回顶部