手机同质化问题越来越严重。 比如去年的手机旗舰处理器基本都是高通855，由于处理器都是一样的，所以只能依靠软件优化来提升性能。 但大家都在跑分，自然就有“作弊”，现在魅族旗下的黑鲨手机已经被“攻陷”了。
根据微博安兔兔评测主编的说法，新黑鲨的得分为43万，UX项的得分显然不科学。 UX项目主要测试用户体验的内容，比如模拟二维码识别速度、html5兼容性等。
从截图中可以看出，黑鲨新机的UX评分高达13万分，而类似配置的红米9只有8万分，相差近60%。 如此大的分数差异让人很难相信是通过正常的优化。 实现了。 而这个5万分的差距安兔兔html5测试分数，正是普通高通855手机的37万到38万分与黑鲨新机43万分的差距。
目前安兔兔已经紧急更新7.2.6版本。 在版本更新中，其承认“修复了系统权限被部分厂商恶意使用，导致UX跑分异常的问题”。 几乎没有直接写黑鲨。 制造商的名称。
目前，手机厂商的竞争确实很激烈。 通过提升体验、满足用户需求来赢得竞争还可以理解，但通过作弊获取假分数就有点过分了。
据传闻，这款黑鲨手机不仅采用高通855处理器，还采用了19.5:9 2340*1080全面屏、液冷、后置双摄、快充等，并将延续游戏手机的传统。 优化和设置。
目前安兔兔html5测试分数，黑鲨手机尚未对此事做出回应。 对于跑分作弊你怎么看？
转载请注明出处：Key/Value之王Memcached初探：三、Memcached解决Session分布式存储场景的应用
1. 高可用会话服务器场景介绍 1.1 应用服务器无状态特性
应用层服务器（这里通常指Web服务器）处理网站应用的业务逻辑，而应用最明显的特征之一就是：应用的无状态性。
PS：说到无状态特性就不得不说一下Http契约。 我们经常看到Http是一个无状态的合约。 同一会话的两个连续请求无法相互理解。 它们由最新的实例化环境解决。 不仅应用程序本身拥有全局对象中可能已存储的所有信息，环境也不保存任何与会话相关的信息。 我们之所以在ASP.NET WebForm的开发中感受不到Http的无状态特性，完全是因为微软帮我们实现了ViewState，ViewState是ASP.NET WebForm中存储页面信息的基本单位。 它本质上是 HTML 中的隐藏对象。 域，反弹时会将这个隐藏域中的数据提交给服务器。
在很多场景下，用户需要与我们的网站系统进行多次交互。 这时就需要一种解决方案来克服无状态特性带来的困境。 幸运的是，在巨人的右臂上，我们已经有了很好的解决方案，那就是浏览器端的Cookie和服务器端的Session。 在平时的单机开发中（这里通常指只有一台Web服务器的情况），我们一般在服务器端使用Session来存储用户登录状态（通常是自定义的对象实例），在大多数管理信息系统开发中（虽然内部系统用户不多，但提供Web服务、存储Session对象的Web服务器是很常见的（显存还是够用的）。
但在大量用户下，单机版的Session会变得效率低下，甚至影响Web服务器的性能。 这是因为：每个用户的Http请求发送到服务器后，每个Web服务器的服务器软件（如：IIS、Tomcat等）都会创建一个线程供该请求处理和响应，一台服务器虽然一次可以接收的请求数量是有限的（这取决于服务器的配置，例如i3、i5、i7类型的CPU可以创建的线程数是不同的） ），当在某一段时间内出现大量并发请求时（例如：网购秒杀系统中，往往同时出现海量并发），那么这台应用服务器将会受到前所未有的请求负载，并且最终可能会因高负载而导致停机，网站不得不停止服务。
这时，我又想起了那句话：当一头牛拉不动火车时，不要找更强的牛，而是用两只牛来拉车。 因此，我们可以利用服务器集群技术对Web服务器进行改进，减少N台Web服务器部署同一个Web应用，形成Web服务器集群对外提供服务，并使用负载均衡设备或软件来平均平衡各个Web服务器的负载。海量并发请求。 传播到每台Web服务器，例如：假设促销活动时系统同时洪泛10万个请求，服务器集群中有5台Web服务器同时提供服务，那么负载均衡设备将发送这10万个请求请求通过一定的算法，以相对均衡的方式分配给Web服务器。 平均每台服务器最多只能承载2万个请求。
通过服务器集群，请求负载问题得到了较好的解决，但是新的问题又出现了：因为Session默认是进程内的（InProc），也就是说它是保存在Web服务器的显存中的。 集群建立后，用户的会话将建立在负载均衡设备分配的一台Web服务器上。 而当用户下次访问或访问系统中的其他子系统时（例如：我先登录百度百科，然后访问百度贴吧），由于Session会话仍然保存在上次提供服务的Web服务器上、系统校准规则（当前web服务器检查用户没有session）会导致用户重复登录（比如：都是百度的网页，但是却允许你多次登录，是你高兴吗？显然，不高兴）。 这时候我们就需要解决Web服务器集群的Session管理。 我们来看看如何管理Web服务器集群的Session。
1.2 应用服务器集群的会话管理
现在我们来看看集群环境下Session管理的几种常用方法：
①会话复制：该方案简单、易于实现。 Session 对象在集群中的多个服务器之间同步。 如果任何服务器宕机，Session对象都不会丢失html5存储，服务器只需要从本机获取即可。 而且，该解决方案仅适用于小型集群。 当规模较大时，大量的Session复制操作会占用服务器和网络的大量资源，导致系统不堪重负。
②会话绑定：借助负载均衡的源地址Hash算法，来自同一IP地址的请求始终分发到同一台服务器。 这样，在整个会话过程中，所有的用户请求都在同一台服务器上处理，即将Session绑定到特定的服务器上，保证在这台服务器上始终能够获取到Session。 （这些场景也称为会话粘性）。
然而，这些解决方案都不能满足高可用性的要求。 因为一旦某个服务器宕机了，该机器上的Session就不再存在了。 用户请求切换到其他机器后，由于没有Session，导致业务流程无法完成。 因此，很少有网站使用这种解决方案进行会话管理。
③Cookie记录会话：借助浏览器支持的cookie来记录会话，简单易行，可用性高，支持服务器线性扩展。 出于这个原因，许多网站或多或少地使用cookie来记录会话。 而且cookie记录会话也存在缺点：比如受到cookie大小的限制，每次响应请求时都会传输cookie影响性能，用户关闭cookie会导致异常访问等
④Session服务器：使用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session时都会访问Session服务器。 这些解决方案实际上将应用服务器的状态分离为无状态应用服务器和有状态会话服务器。
从前面的方法来看，各有优缺点，但Session服务器是最能满足高可用性要求的方案，也是企业经常使用的方案。 所以，对于有状态的Session服务器，更简单的办法是使用分布式缓存（如Memcached、Redis等，关于Redis的简单介绍，可以阅读我的博文：NoSQL初步探索：人人都爱Redis）、数据库等，在此产品的基础上进行封装，使其满足Session的存储和访问需求。 基于上面的介绍html5存储，明天我们将使用Memcached来搭建我们的Session服务器，来解决Web服务器集群中Session的共享访问。
PS：为什么使用分布式缓存方案而不是数据库来存储Session？ 这就需要对数据访问的性能困境进行分析。 一般来说，C盘的IO读写速度是最慢的，因为虽然数据库数据都是以文件的形式存储的，虽然目前大多数数据库都采用B+树结构，但是读取一条数据仍然最多需要4次数据读取并写入（三个C盘访问获取数据索引和行ID，一个数据文件读取操作，终于知道数据库操作有多麻烦了）。 Memcached等分布式缓存以Key/Value等简单方式存储在服务器的显存中。 显存的随机读写速度完全可以爆发C盘的IO，所以外网+显存的双内模式是比较完美的。 计划。
C盘分为两种：
①机械硬盘：通过电机驱动盘片臂，将盘片推至指定的C盘位置存取数据。 它还支持快速顺序读取和写入以及缓慢随机读取和写入。
②固态硬盘（又称SSD）：没有机械装置，数据存储在具有永久存储器的硅晶体上，因此可以像显存一样快速、随机地访问。
在当前的网站应用程序中，大多数应用程序随机访问数据。 在这些情况下，SSD性能更好，性价比还有待提高（相当贵，那又怎样）。
2、Memcached实现Session分布式存储2.0案例整体预览
(1) 模拟登录案例场景
假设我们有一个基于ASP.NET的信息系统。 本系统采用统一的系统登录页面进行用户登录。 登录后默认跳转到用户中心首页，显示：欢迎，{用户账户名}。
①系统登录页面的功效：
② 用户主页效果：
(2)模拟技术系统的选择
ASP.NetMVC+EFCodeFirst+MySQL+Memcached
2.1 前期规划工作
（1）新建一个ASP.NETMVC4空项目，选择视图引擎为“Razor”；
（2）在工程中新建一个文件夹，命名为“Lib”，主要存放一些必要的DLL文件；
(3) 在项目中添加对这些DLL的引用。 注意，这里引入EntityFramework.dll是为了支持之前的CodeFirst开发方式。 EF版本必须是4.1或以上。 PS：您还可以通过PackageManager安装EntityFramework。 至此，我们的规划工作就完成了，接完之后就可以开始接下来的工作了。
2.2 使用EFCodeFirst生成MySQL数据库
首先，EF是一个ORM（对象关系映射）框架，它可以将我们在编程中使用的对象映射到底层数据库结构。 ORM框架负责将从数据库返回的记录集转换为对象，还可以根据对象当前的具体状态生成相应的SQL命令并发送给数据库，完成数据访问工作（常见的数据访问操作可以称为CRUD（创建、读取、更新、删除）。
EF给数据库应用系统的开发带来了更高的效率。 使用它可以更轻松地编写易于维护和扩展的系统。 不过，性能实际上不如ADO.NET，但已经足够满足大多数开发需求了。 场景要求。 与ADO.NET不同，EF具有更高层次的表示：它将数据库映射到DbContext，将数据库中访问的数据直接映射到实体（Entity）对象，屏蔽了底层数据库的内部结构，不需要直接使用上层数据访问引擎提供的底层对象（如ADO.NET提供的DbConnection、DbCommands等）完成CRUD。
EF支持三种开发模式：CodeFirst、DatabaseFirst和ModelFirst。 这里我们使用CodeFirst模式，它可以帮助我们达到快速开发迭代的目标。 最后，EF不是本文的重点。 如果你还不了解EF或者CodeFirst，可以参考金旭良老师关于EF骑马看花的系列文章，这里不再赘述。
(1) 在Models文件夹中创建一个新类，并将其命名为“UserInfo”。 作为我们的实体类，它映射到MySQL数据库中的UserInfo表（这里MySQL数据库中并没有创建这样的数据表）
查看代码
（2）在Models文件夹中创建一个新类，命名为“MyDbContext”，使其继承自DbContext，并将其用作EF操作的数据库上下文。 需要注意的是：这里name=MySqlDemo，MySqlDemo是数据库的名称。 而这里的this.Database.CreateIfNotExists()方法是用来判断数据库MySqlDemo是否已经存在的？ 如果不存在，请创建一个。
查看代码
（3）在Web.config中添加新的数据库连接字符串，并将database设置为“MySqlDemo”，与之前MyDbContext中构造函数中的名称一致。
查看代码
至此，由于我们只使用了UserInfo表，所以我们与数据库和EF相关的代码到这里就结束了。
2.3 自行封装Memcached辅助类，提供对外服务socket
（1）在Web.config中添加一个AppSetting，用于保存Memcached服务器的地址列表：
（2）在Models中新建一个类，命名为“MemcachedHelper”。 我们将其设置为静态类，因此方法都是静态的，无需实例化，直接调用即可。 正如你所看到的，我们在这里使用静态构造函数来初始化一个全局静态对象，该对象不属于任何实例，因此这个构造函数只会执行一次，并且在创建该类型的第一个实例或引用任何静态成员之前，由.NET 手动调用。
查看代码
这里我们不配置SockIOPool的列表，只是使用它的默认配置。 并且需要注意的是SockIOPool的PoolName和MemcacheClient的PoolName必须一致。
2.4 当用户登录时，调用Memcached辅助套接字存储用户的登录状态
（1）在Controller中新建一个控制器，命名为“LogonController”。 主要用于显示系统登录页面和进行用户认证的AJAX操作（将用户会话存储到Memcached中也在这个操作中）。 至于登陆页面的HTML和JS脚本，这里不再赘述。 请下载Demo文件自行查看。
查看代码
现在看一下这个控制器的核心代码：
①Action Index主要用于显示登录视图，页面代码不再贴出，直接看下面的AJAX请求代码：使用JQueryAJAX将用户名和密码提交给ValidateUserInfo Action，如果服务器端校验的是成功，返回一个JSON对象，浏览器终端判断success属性是否为true，如果为true则跳转到系统首页。
查看代码
②ValidateUserInfo 该Action根据浏览器提交的AJAX请求判断用户名和密码是否正确。 这里用到了我们刚刚写的MyDbContext，并且先实例化了它。 （这一步很重要，此时我们的MySQL数据库中还没有MySqlDemo数据库，当MyDbContext第一次实例化时，EF会帮我们创建MySQL中的MySqlDemo数据库，虽然其本质是帮我们生成一个string :cratedatabasemysqldemo; 以及其他SQL语句），然后用Lambda表达式漂亮的句型来校准。 如果您对Lambda表达式不熟悉，可以参考MSDN的《Lambda表达式（C#编程手册）》文章进行学习。
③是核心部分。 我们使用Guid（保证Key的唯一性）作为SessionId写入浏览器端的cookie中，并将其作为Key存储在Memcached分布式缓存中，并为其设置一个默认的过期时间（这里是20分钟） ）。 以后，浏览器每次向服务器提交请求时，都会在HTTP报文中附加cookie，服务器就可以用cookie作为Key来查找Memcached服务器中的Session对象。
PS：一般来说，Memcached数据key的命名是有讲究的。 这里传智老马推荐一个命名规则：{命名空间}-{部门名称}-{项目名称}。 这里简单点，使用Guid作为Key，因为每次生成的Guid都是唯一的。
2.5 封装BaseController，解决Action触发前的标定规则
(1)在往年的信息系统项目开发中，我们会在系统中做一个全局的校准器，来判断用户的每个操作请求是否具有相应的权限。 这里我们主要校准用户是否登录，这样我们就可以在模块中具体获取用户的Session对象。 单机的情况下，我们通常会将Session保存在本地进程中，所以我们主要判断Session中是否有登录状态。 这里我们使用Memcached来存储Session对象，所以我们在每个Action执行前添加一条规则：判断Memcached中是否存在当前用户的登录状态，如果有则继续执行该Action。 如果没有，抱歉，请登录。
（2）在WebForm中，我们可以写一个BasePage，让它继承自Page，重绘OnLoad风暴，让其他页面继承BasePage，那么我们就可以将这个校准应用到所有继承BasePage的Page类中。 。 这样，在MVC模式下，请求对象不再是xxx.aspx页面类型，而是/ControllerName/ActionName的路由，所以我们需要为Action找到一个全局的过滤方法。 那么，说到这里我们不禁想到了一个高级英语：AoP（面向切面编程），这是软件开发中的一个热门话题。 借助AOP，可以隔离各部分业务逻辑，从而促使各部分业务逻辑之间的耦合程度增加，提高了程序的可重用性，同时提高了开发效率。 因此，我们减少Actions的全局标定规则，将Actions的标定方法与Actions的业务处理分离，增加它们的耦合性，提高Actions的标定方法的复用性，这符合AoP的思想。 那么，说了半天，在ASP.NETMVC中如何实现呢？ 别怕，我们可以写一个BaseController来像BasePage一样处理，让它继承自Controller，然后再从BaseController继承其他需要用用户登录状态进行校准的Controller。
查看代码
(3)现在我们看一下里面的代码：
