皮皮网

1.AndroidFramework 之启动 ServiceManager
2.模安卓拟器怎么修改imei
3.深度分析 | MGR相同GTID产生不同transaction故障分析

AndroidFramework 之启动 ServiceManager

        ServiceManagaer 是 Binder 的守护进程，在 Binder 机制中起着重要的作用。本文将从源码的角度对其进行分析，整体流程如下：

        时序图如下。

        先来看看 ServiceManager 是如何启动的：

        在 Zygote 一文中说过， init 进程启动的第二阶段会解析 init.rc 文件。

        在这之后会触发 trigger init 。

        结合 init.rc 看看 action init 做了什么。

        当触发 trigger init 后，会启动 servicemanager 服务，其声明如下。

        对应的执行文件为 /system/bin/servicemanager ，在编译前位于 frameworks/native/cmds/servicemanager 下，来看看 Android.bp 。

        其对应的源码为 service_manager.c 和 binder.c ，入口函数 main() 位于 servicemanager.c 。

        启动完 ServiceManager 后会打开 Binder 驱动。

        在 main() 中首先调用 binder_open() 。

        binder_open() 主要做了如下事情：

        给结构体 binder_state 分配内存。

        系统调用 open() 打开 /dev/binder ，如果打开驱动失败，则执行 fail_open 释放内存。

        简单的解释一下什么是系统调用？

        由于需要限制不同的程序之间的访问能力，防止程序获取别的程序的内存数据， CPU 划分出两个权限等级，用户态和 内核态。

        所有的用户程序都是运行在用户态，但有时需要做一些内核态的事情，而唯一可以做这些事情的就是操作系统，所以程序需要向操作系统发起请求，以程序的名字来执行这些操作。这时就需要一个从用户态切换到内核态但不能控制内核态中执行的机制，这种机制就是 系统调用。

        系统调用 ioctl() 传入 BINDER_VERSION 命令获取 Binder 驱动版本，对比版本是否一致，不一致则执行 fail_open 释放内存。

        系统调用 mmap() 映射 kb 的内存空间，即把 Binder 驱动文件的 kb 映射到内存空间供 ServiceManager 使用，内存映射失败则执行 fail_map ，关闭 fd 并释放内存。

        ServiceManager 进程 mmap 的内存大小可以通过 adb shell 命令查看。

        可以看到内存映射地址为 0xff ~ 0xf ，差为 0x 即十进制的 kb 。

        打开 Binder 驱动后会将 ServiceManager 设置为上下文管理者。

        调用 binder_become_context_manager() 。

        android 新增 BINDER_SET_CONTEXT_MGR_EXT 命令来设置安全的上下文管理者，如果设置失败，则使用原有的 BINDER_SET_CONTEXT_MGR 命令来设置上下文管理者，两者区别在于是否携带参数。

        最后会进入循环，从 Binder 驱动读取和解析数据。

        调用 binder_loop() 进入循环，不断地通过系统调用 ioctl() 从 Binder 驱动读取数据，并通过 binder_parse() 进行数据解析。

        注意这里调用 binder_loop() 传入的 svcmgr_handler() ，后面会使用到。

        binder_write() 会封装 struct binder_write_read ，并通过系统调用 ioctl() 将对应的命令传递给 Binder 驱动。

        binder_parse() 用来解析从 Binder 驱动读取到的数据，然后根据不同的命令执行对应的操作。

        因为 cmd 命令可能有多个，所以通过 while 循环每次处理一个 cmd 命令，多 cmd 的结构大致如下图所示。

        这里重点看下 BR_TRANSACTION 命令。

        BR_TRANSACTION 是 Binder 驱动向 Server 端发送请求数据。

        binder_transaction_data 的结构如下，其表明了 transcation 传输的具体语义，语义码记录在 code 中，不同语义码携带的数据是不同的，这些数据由 data 指定。

        在解析完 binder_transaction_data 的具体语义后，会调用前面传给 binder_loop() 的 svcmgr_handler() ，其实就是 switch case 语义码做不同的事情。

        ServiceManager 的功能其实很简单：

        至此 ServiceManager 就分析完了。

模安卓拟器怎么修改imei

       imei是系统硬件标识

       无法修改的,除非你去改android系统的源代码

       TelephonyManager TelephonyMgr = (TelephonyManager)getSystemService(TELEPHONY_SERVICE);

       TelephonyMgr.getDeviceId(); //这里就是获取IMEI,你只能去改系统代码,把这里的回返值改成固定的

深度分析 | MGR相同GTID产生不同transaction故障分析

       在MGR高可用方案的使用中，我们经常会遇到因网络抖动导致集群故障的情况。最近，某客户遇到了一个具体问题，即在生产环境中的一组MGR集群中，虽然在相同的自动画线支撑压力指标源码GTIDafbf-1b8c-e8-f-a4:下执行了相同的事务，但binlog日志显示了不同的事务信息。具体现象是，primary节点执行了对world.IC_WB_RELEASE表的insert操作，但这一操作没有同步到secondary节点，导致secondary节点的数据与primary节点不一致。当表IC_WB_RELEASE发生delete操作时，这一数据不一致引发故障，使从节点脱离集群。

       为深入分析此问题，我们首先考察了主从实例在GTID相同但事务不同的原因。这一问题可能与特定的阳光酒店源码bug相关联，重点在于MGR同步事务的时序。MGR全组同步数据的Xcom组件基于paxos算法实现，每次提交新生事务时，主实例会将新生事务发送给从实例进行协商。在组内协商通过后，全组成员一起提交事务。每个节点以相同的顺序接收相同的事务日志，从而保持一致的源码直装状态。

       在paxos算法中，有两个关键角色：提议者和接受者。算法的达成共识过程分为两个阶段。针对本文案例，我们需关注以下几个关键点：primary节点执行insert操作，向组内发送准备请求并收到大多数成员的确认，然后发送接受请求。同时，识别编码源码其他从节点由于网络原因未能接收到主实例的accept请求。其中一台从实例开始新的prepare请求，请求的值为no_op（空操作），并使用一个较大的ballot值（节点编号）。其他从实例由于收到过主节点的值，因此将主节点的提案作为新的提案，覆盖了主实例的提案，导致主实例的抢包包源码提案未被接受。

       结合源码中的handle_ack_prepare逻辑，我们分析了这一过程。在accept阶段，主节点收到组内大多数成员的确认并接收到自己的learn_op信息，因此提交了自己的提案（binlog中的insert操作）。而其他实例的提案为no_op，因此没有进行任何事务提交。此时，主实例的GTID大于其他从实例的GTID，导致主从binlog中GTID相同但事务不同的现象。

       当业务执行到对表world.IC_WB_RELEASE的delete操作时，主实例能够执行操作，而其他实例由于没有执行过插入操作，无法进行删除，从而导致集群分裂。这一过程总结了故障的根本原因。

       为解决此问题，我们向官方提交了SR，并得到了反馈，修复将应用于社区版MySQL 5.7.和MySQL 8.0.中。对于使用企业版的客户，可申请最新的hotfix版本。在升级MySQL版本之前，如果再次遇到此类故障，需人工检查切换时binlog中的GTID信息与新主节点对应GTID的信息是否一致。如果不一致，需要人工修复至一致状态，确保原主节点能够安全加回集群。

       对于使用MGR 5.7.之前社区版的DBA，需注意避免此类故障。爱可生开源社区提供了丰富的资源和指导，包括DBLE系列公开课、技术分享、使用指南和深度分析文章等。同时，开源分布式中间件DBLE和数据传输中间件DTLE的社区官网和GitHub主页提供了进一步的技术支持和交流。