资讯频道 → 数据库
阅读更多

0顶
0踩

数据库

原创新闻 MySQL Group Replication调研剖析

2017-01-23 10:18 by 副主编 jihong10102006 评论(1) 有7696人浏览
mysql

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

引用
作者简介：王伟，京东基础平台数据库工程师，京东商城基础平台部门包括大规模容器集群调度、数据库与存储技术、消息系统与服务框架、架构与运维、机器学习与人工智能等技术方向。
京东商城首席架构师刘海锋担任部门负责人。基础平台运营多个数据中心数万台服务器，支撑京东无数在线业务。团队官方公众号：ipdchat，会定期推送技术干货，欢迎关注！

一. MySQL复制的三种模式
MySQL当前存在的三种复制模式有：异步模式、半同步模式和组复制模式，先了解一下三种模式的工作方式。

1. MySQL Asynchronous Replication(异步复制)
异步复制是MySQL最早的也是当前使用最多的复制模式，异步复制提供了一种简单的主-从复制方法，包含一个主库（master）和备库（一个，或者多个）之间，主库执行并提交了事务，在这之后（因此才称之为异步），这些事务才在从库上重新执行一遍（基于statement）或者变更数据内容（基于row），主库不检测其从库上的同步情况。在服务器负载高、服务压力大的情况下主从产生延迟一直是其诟病。工作流程简图如下：

2. MySQL Semisynchronous Replication（半同步复制）
MySQL5.5的版本在一步同步的基础之上，以插件的形式实现了一个变种的同步方案，称之为半同步（semi-sync replication）。这个插件在源生的异步复制上，添加了一个同步的过程：当从库接收到了主库的变更（即事务）时，会通知主库。主库上的操作有两种：接收到这个通知以后才去commit事务；接受到之后释放session。这两种方式是由主库上的具体配置决定的。当主库收不到从库的变更通知超时时，由半同步复制自动切换到异步同步，这样就极大了保证了数据的一致性（至少一个从库），但是在性能上有所下降，特别是在网络不稳定的情况下，半同步和同步之间来回切换，对正常的业务是有影响的。其工作流程简图如下：

3. Group Replication（组复制）
不论是异步复制还是半同步复制，都是一个主下面一个从或是多个从的模式，在高并发下高负载下，都存在延迟情况，此时如果主节点出现异常，那么就会出现数据不一致的情况，数据可能会丢，在金融级数据库中是不能容忍的。在这种情况下，急需出现一种模式来解决这些问题。在MySQL5.7.17的版本中，带着这些期待，新的复制模式组复制产生并GA了（本文的测试等数据均基于MySQL5.7.17）。

组复制的工作流程图如下：


二. 组复制的工作原理
MySQL组复制是一个MySQL插件，它建立在现有的MySQL复制基础结构上，利用了二进制日志，基于行的日志记录和全局事务标识符等功能。它集成了当前的MySQL框架，如性能模式、插件和服务基础设施等。

组复制（Group Replication）基于分布式一致性算法(Paxos协议的变体)实现，一个组允许部分节点挂掉，只要保证绝大多数节点仍然存活并且之间的通讯是没有问题的，那么这个组对外仍然能够提供服务，它是一种被使用在容错系统中的技术。Group Replication（复制组）是由能够相互通信的多个服务器（节点）组成的。在通信层，Group replication实现了一系列的机制：比如原子消息（atomic message delivery）和全序化消息（total ordering of messages）。这些原子化，抽象化的机制，为实现更先进的数据库复制方案提供了强有力的支持。MySQL Group Replication正是基于这些技术和概念，实现了一种多主全更新的复制协议。简而言之，一个Group Replication就是一组节点，每个节点都可以独立执行事务，而读写事务则会在于group内的其他节点进行协调之后再commit。因此，当一个事务准备提交时，会自动在group内进行原子性的广播，告知其他节点变更了什么内容/执行了什么事务。这种原子广播的方式，使得这个事务在每一个节点上都保持着同样顺序。这意味着每一个节点都以同样的顺序，接收到了同样的事务日志，所以每一个节点以同样的顺序重演了这些事务日志，最终整个group保持了完全一致的状态。然而，不同的节点上执行的事务之间有可能存在资源争用。这种现象容易出现在两个不同的并发事务上。假设在不同的节点上有两个并发事务，更新了同一行数据，那么就会发生资源争用。面对这种情况，Group Replication判定先提交的事务为有效事务，会在整个group里面重放，后提交的事务会直接中断，或者回滚，最后丢弃掉。因此，这也是一个无共享的复制方案，每一个节点都保存了完整的数据副本。

从其工作的原理可以看出，Group Replication基于Paxos协议的一致性算法校验事务执行是否有冲突，然后顺序执行事务，达到最终的数据一致性，也就意味着部分节点可以存在延迟。可以设置多主同时写入和单主写入，通过设置group_replication_single_primary_mode来进行控制是多主还是单主，官方推荐单主写入，允许延迟，但延迟过大，则会触发限流规则（可配置的），整个集群会变的很慢，性能大打折扣。

三. 组复制的程序结构
在MySQL的底层，GR增加了另外的API层来实现所需要的功能。程序结构上，GRAPI主要分为三部分：
  • 1:capture 追踪当前正在执行的事务的上下文。
  • 2:applier 执行远程事务传输到本地的日志到本地数据库。
  • 3:recovery 负责分布式环境下的节点恢复，以及相关的数据回追，失败处理等。

在这几个主要API层的下面，是统一的复制协议逻辑处理层，这一层主要是统一应用层的各种调用。在更下层，则是通用程度更高的分布式通讯层，处于调用便利，分布式通讯曾对上提供使用的API，API的下面，是Paxos实现的分布式通讯协议组件，这个组件与集群中其他节点一起，形成一个虚拟概念化的分布式集群。


四. 消息压缩（Message Compression）
这个压缩主要是指MySQL的bin-log压缩，所使用的压缩算法是LZ4。当网络带宽是瓶颈时，消息压缩可以在组通信级别提供高达30-40％的吞吐量改进，这在网络传输压力比较大的组中是尤为重要的。LZ4能很好的支持多线程环境，获得更高的压缩和解压速度。以下是压缩算法LZ4的压缩和解压情况：

压缩发生在组通信引擎级别，之前数据被交给组通信线程，所以它发生在mysql用户会话线程的上下文中。事务有效网络负载可以在被发送到组之前被压缩，并且在被接收时被解压缩。压缩是有条件的，并且取决于配置的阈值。默认情况下启用压缩，此外，它并不要求组中的所有服务器节点都启用压缩机制，在接收到消息时，成员检查消息信封以验证它是否被压缩，如果需要，则成员解压缩该事务，然后将其传递到上层。

默认情况下启用压缩，阈值为1000000字节（1MB）。压缩阈值（以字节为单位）可以设置为大于默认值。在这种情况下，只有具有大于阈值的有效负载的事务被压缩。下面是如何设置压缩阈值的示例。 
STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold= 2097152;
START GROUP_REPLICATION;

这将压缩阈值设置为2MB。如果事务生成的有效内容大于2MB的复制消息，例如大于2MB的二进制日志事务条目，则会对其进行压缩。禁用压缩设置阈值为0。注意：修改这个阈值是需要重启组复制的。

消息压缩流程图如下：


五. 组复制的要求和限制
1.限制和要求
  • 所有涉及的数据都必须发生在InnoDB存储引擎的表内。
  • 所有的表必须有明确的主键定义。
  • 网络地址只支持IPv4。
  • 需要低延迟，高带宽的网络。
  • 目前集群限制最多允许9个节点。
  • 必须启用binlog。
  • binlog 格式必须是row格式。
  • 必须打开gtid模式。
  • 复制相关信息必须使用表存储。
  • 事务写集合（Transaction write set extraction）必须打开。（这个目前与savepoint冲突，这也是导致mysqldump无法备份GR实例的原因）
  • log slave updates必须打开。
  • binlog的checksum目前不支持。
  • 由于事务写集合的干扰，无法使用savepoint。
  • SERIALIZABLE 隔离级别目前不支持。
  • 对同一个对象，在集群中不同的实例上，并行地执行DDL（哪怕是相互冲突的DDL）是可行的，但会导致数据一致性等方面的错误，目前阶段不支持在多节点同时执行同一对象的DDL。
  • 外键的级联约束操作目前的实现并不完全支持，不推荐使用。
2.组复制的相关配置
依据组复制的要求和限制，以下设置根据MySQL组复制要求配置复制： 
server_id = 1
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW

此时my.cnf文件可确保服务器配置，并指示实例化一个给定的配置下的复制基础设施。以下部分配置服务器的组复制设置。具体参数比较简单，不在这里赘述，可参见官方说明： 
transaction_write_set_extraction = XXHASH64
loose-group_replication_group_name =“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”
loose-group_replication_start_on_boot = off
loose-group_replication_local_address ="127.0.0.1:24901”
loose-group_replication_group_seeds =“127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903”
loose-group_replication_bootstrap_group = off


六. 组复制的多主和单主模式（Multi-Primary or Single-Primary Mode）
组复制分为多主和单主两种模式，默认是单主模式，也是官方推荐的组复制模式。单个集群中不能同时使用两种模式，例如一个配置在多主模式，而另一个在单主模式。要在模式之间切换，需要使用不同的操作配置重新启动集群。无论部署模式如何，组复制不处理客户端故障切换，它必须由应用程序本身、连接器或中间件框架（如代理或路由器）等处理。

1.单主模式
在此模式下，组具有设置为读写模式的单主实例，主节点通常是用于解析组的第一个服务器，组中的其他其他节点都自动设置为只读模式（即，超级只读），所有其他加入的节点自动识别主节点并设置为自己为只读。

在单主机模式下，将禁用在多主机模式下部署的某些检查，因为系统会强制每次只有一个写入节点。例如，允许对具有级联外键的表进行更改，而在多主模式下不允许。在主节点故障时，自动选举机制选择下一个主节点。通过按字典顺序（使用其UUID）并选择列表中的第一个节点来排序剩余的节点来选择下一个主节点。如果主节点从组中删除，则执行选择，并从组中的其余节点中选择新的主节点，这个选择按照词典顺序排序节点UUID并选择第一个来执行。一旦选择了新的主节点，其他节点将设置为从节点，从节点为只读。如下图：


2.多主模式
在多主模式下，没有单个主模式的概念，也没有选举程序，因为没有节点发挥任何特殊的作用。加入组时，所有服务器都设置为读写模式。

在多主要模式下部署时，将检查语句以确保它们与模式兼容。在以多主模式部署组复制时进行以下检查：

1:如果事务在SERIALIZABLE隔离级别下执行，则在将其与组同步时，它的提交将失败。
2:如果事务对具有级联约束的外键执行，则事务在与组同步时无法提交。
这些检查可通过设置选项停用 group_replication_enforce_update_everywhere_checks 到FALSE。当在单主要方式部署，该选项必须设置为 FALSE。如下图：


七. 运维相关问题
1.故障切换问题
目前MySQL官方没有发布连接组复制专用的客户端（如MongoDB连接复制集的客户端），在实际的应用中如果发生故障，需要客户端自己来处理。对于单主模式的话，如果主节点发生故障，客户端需要判断新的主节点是谁，然后把写切换到新的主节点，基本上和当前的异步同步的主从切换一样，并且新的主节点是集群自动产生，不可控；多主模式需要在客户端进行节点可用性检查，当其中的一个写节点不可用时自动使用其他可用节点。

在实际生产中，综合两种组复制模式的故障切换，可以使用多主模式，指定其中一个节点为主节点，其他节点置为只读节点，这样主节点故障时，新的主节点可控。

2.大事务支持问题
目前版本测试并发进行大数据操作和DDL操作时，kill掉大事务，有几率造成集群不可用；在insert into …….select……limit……这种大事务支持不好，可能造成集群不用；多主模式进行DDL操作需要集群内所有节点都为ONLINE状态才可执行，处于ERROR和RECOVERING状态时有几率导致集群堵塞，严重时集群不可用。

3.备份问题
在组复制集群其中的一个节点上执行数据库备份时，不管使用mysqldump（这个不能使用–single-transaction参数，生产中不建议使用mysqldump备份集群数据）或是使用xtrabackup集群MySQL的QPS下降40%，并且备份节点基本停止读写。在测试备份文件导入数据时，多主模式要比单主模式慢。推荐使用组复制+异步复制方式，在异步复制的从节点上进行数据库备份。

4.二进制日志删除问题
因为组复制同步还是基于二进制日志来进行同步的，清理某个节点bin-log时，必须判定这个日志文件是否还在使用，如果在使用，则绝对不能删除，如果删除，则整个集群直接ERROR。

5.同步延迟问题
目前MySQL5.7.17的版本中无法直观查看节点同步延迟，也无法获取延迟多少，不管是时间或事物数，这个打开MySQL的Debug模式，可以获取到节点的延迟事务情况。

组复制的延迟对集群是有影响的，一旦出现延迟（默认延迟25000个事务），则启动流量控制（Flow Control），每个周期性能衰减当前的10%,直到集群不可用（但集群节点状态为online），单个节点慢整个集群全慢。

集群中的每个节点都会验证并应用该组提交的事务，有关校验和应用程序过程的统计信息对于了解应用程序队列如何增长，已找到多少冲突，检查了多少事务，在哪里提交了哪些事务等等非常有用。表 performance_schema.replication_group_member_stats 提供与事务认证过程的相关信息，但没有延迟信息。相关字段解释如下：


6.数据一致性问题
不管是多写还是单写，都并非是强一致性，均允许有延迟，他在校验完事务是否冲突后把当前广播到各个节点并确定各个节点收到事务后即进入下一个事物的冲突检测，此时每个节点只是拿到了所有事务的执行序列，保证了事务最终顺序执行，从而保证数据的最终一致性，但同一时刻并非强一致性的。

7.节点故障脑裂问题
节点越多性能损耗越大，三个节点比较合适。节点故障可能有脑裂等问题：如5个节点分布在两个机房，机房间网络断掉分为两个部分，2个集群的机房不可用，3个节点的可用，而三个节点的机房网络有问题，此时如果想使两个节点的机房可用，需要重新对两个节点做集群重组，三个节点的就无法恢复到两个节点中去；三节点中其中一个节点宕机，其他两个正常节点可用，故障节点重启没有加入到集群时，此时这个节点以单实例存在可读写，此时会发生脑裂。

8.网络延迟问题
测试过程中使用TC命令来模拟网络延迟： 
tc qdisc add dev eth0 root netem delay 50ms 10ms 增加网络延迟50ms，10ms左右的浮动
tc qdisc del dev eth0 root netem delay 50ms 10ms 删除网络延迟

经过测试网络延迟对比组复制MySQL的QPS：网络延迟设置50ms和正常的对比，QPS降低至少1/3，甚至1/2，网络延迟对性能影响挺大。以下是测试情况：


9.弹性扩展问题
MySQL官方网站提到了组复制的弹性自动扩展，经过实际测试，这种扩展在生产中是不现实的。可用于生产的弹性扩展要求新加入一个集群，集群中的数据完全由集群来完成自动同步，但由于组复制是基于二进制日志来进行同步的，生产中是不可能完整保留全部的二进制日志，在新加入的节点需要先备份出集群的全量数据，然后根据同步位置去追事务达到数据的一致后节点状态online状态，其实和之前异步同步搭建主从一样。并且官方提示如果恢复时的延迟过大，可能也无法正常达到追到最新数据的位置。

10.客户端连接问题
官方说明中关于故障处理的时候有一句话：组复制不处理客户端故障切换，它必须由应用程序本身，连接器或中间件框架（如代理或路由器）处理。官方一再强调MySQL组复制提供了高可用、高弹性、可靠的MySQL服务，那么官方是否提供一套类似MongoDB复制集的客户端组件来支持那？

目前的解决方法就是和异步复制的切换差不多，使用域名切换或是自己实现一套高可用的客户端连接方式。但就目前来说效率最高的是结合自己的业务，修改组复制故障处理的源码，当检测到写节点故障时结合自己的域名切换来处理。但这样对DBA来说需要源码开发能力，相对要求比较高。

11.查找主节点IP问题
在单主模式下，不能直观的获取主库的IP地址，使用以下命令可以获取到主节点的UUID： 
mysql> SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME ='group_replication_primary_member';
+ -------------------------------------- +
| VARIABLE_VALUE |
+ -------------------------------------- +
| 69e1a3b8-8397-11e6-8e67-bf68cbc061a4 |
+ -------------------------------------- +
1行（0,00秒）

使用SELECT * FROM performance_schema.replication_group_members可以查看到UUID对应到的MEMBER_HOST，而MEMBER_HOST指的是主机名，需要在MySQL的配置文件中指定report-host为IP地址，这样就可以两个表关联查询到主库的IP地址。


八. 总结
从测试的情况来看，对大事务等的支持不够，运维管理方面做的不友好，相关组复制的配套监控、客户端等不完善，有一部分问题是可以规避和曲线解决的，有一部分需要源码层面的支持；在性能上和PXC对比，要优于PXC，这个和各自的复制协议不同分不开的。

MySQL组复制提供了高可用、高弹性、可靠的MySQL服务，旨在打造金融级MySQL集群。在忽略网络延迟的情况，可以轻松的实现多活和异地调用就近写库，这一点是业务上比较期待的。组复制是MySQL未来的一个发展趋势，相信在未来的版本中会更加的完善，期待成熟版本。

参考文档：http://dev.mysql.com/doc/refman/5.7/en/group-replication.html
  • 大小: 17.8 KB
  • 大小: 20.4 KB
  • 大小: 23.2 KB
  • 大小: 52.4 KB
  • 大小: 30.8 KB
  • 大小: 49.1 KB
  • 大小: 31.4 KB
  • 大小: 32.8 KB
  • 大小: 13.7 KB
  • 大小: 147.2 KB
  • 大小: 30 KB
0
顶
0
踩
评论 共 1 条 请登录后发表评论
1 楼 针尖上的舞者 2017-01-23 18:16
请问组复制和第一种异步复制的区别在哪里呢,没看出来

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • 02-MySQL Group Replication技术实现分析-温正湖

    2016-12-12，一个重要的日子，mysql5.7.17 GA版发布，正式推出Group Replication(组复制) 插件，通过这个插件增强了mysql原有的高可用方案(原有的Replication方案)，提供了重要的特性——多写，保证组内高可用，确保...

  • 从源码分析 MySQL Group Replication 的流控机制

    Group Replication 是一种 Shared-Nothing 的架构，每个节点都会保留一份数据。 虽然支持多点写入，但实际上系统的吞吐量是由处理能力最弱的那个节点决定的。 如果各个节点的处理能力参差不齐，那处理能力慢的节点就...

  • 检查mysql的replication_MySQL Group Replication冲突检测机制再剖析

    《MySQL MGR事务认证机制优化》一文对MySQL Group Replication(MGR)的事务认证/冲突检测机制实现进行了介绍，并分析了其潜在的问题。本文将从certification_info对象，即冲突检测数据库实现作为切入点，来重点分析...

  • mysql group 更新递增_MySQL Group Replication在网易使用和优化实践

    本文由作者授权网易云发布，未经许可，请勿转载作者：温正湖，网易数据库技术专家MGR(MySQL Group Replication)是MySQL官方推出的领先的服务高可用和数据高可靠方案，网易从2017年下半年开始对MGR进行了全面的性能和...

  • 从源码分析 MySQL Group Replication 的新主选举算法

    结合代码和上面四个案例的分析，最后我们总结下 MGR 的新主选举算法：如果集群中存在 MySQL 5.7 的节点，则会将 MySQL 5.7 的节点作为候选节点。如果最小版本小于 MySQL 8.0.17，则所有的节点都可作为候选节点。如果...

  • mysql shrink_MySQL Group Replication内存使用分析和优化-1

    本文主要分析MySQL Group Replication(MGR)相比传统MySQL复制模式，mysqld新增的几个内存缓存模块。举例说明由此可能引发的问题，并介绍潜在的优化方案。与传统的MySQL主从复制不同，MySQL Group Replication模式下...

  • Mysql Group Replication

    1 What's Group Replication 2 配置要求与限制 2.1 数据库要求 2.1.1 innodb引擎 2.1.3 隔离级别 2.1.4 外键 2.1.5 IPv4网络，网络性能稳定延迟小带宽充足 2.1.6 自增跟步长 2.2 安装mysql_...

  • MySQL Group Replication增加节点

    在上一篇文章中，我们大概介绍了Mysql Group Replication的构架及集群搭建步骤。那么我们知道，一组优秀的集群环境有一个很必要的特性，那就是可拓展性。Group Replication的拓展性怎么样呢？我们设定如下几个场景，...

  • MySQL Group Replication Got fatal error 1236

    Slave I/O for channel 'group_replication_recovery': Got fatal error 1236 from master when reading data from binary log

  • MySQL8.0-Replication简介和配置

    mysql复制简介

  • MySQL Group Replication 技术点

    mysql group replication，组复制，提供了多写(multi-master update)的特性，增强了原有的mysql的高可用架构。mysql group replication基于mysql插件架构实现，本身就是一个mysql插件。 提供的特性: 多写，写...

  • 人力资源经理绩效考核表.xls

    人力资源经理绩效考核表

  • 智慧环卫管理平台建设方案Word(211页).docx

    一、智慧环卫管理平台的建设背景与目标 智慧环卫管理平台的建设源于对环卫管理全面升级的需求。当前，城管局已拥有139辆配备车载GPS系统、摄像头和油耗传感器的环卫车辆，但环卫人员尚未配备智能移动终端，公厕也缺乏信息化系统和智能终端设备。为了提升环卫作业效率、实现精细化管理并节省开支，智慧环卫管理平台应运而生。该平台旨在通过信息化技术和软硬件设备，如车载智能终端和环卫手机App，实时了解环卫人员、车辆的工作状态、信息和历史记录，使环卫作业管理透明化、精细化。同时，平台还期望通过数据模型搭建和数据研读，实现更合理的环卫动态资源配置，为环卫工作的科学、健康、持续发展提供决策支持。 二、智慧环卫管理平台的建设内容与功能 智慧环卫管理平台的建设内容包括运行机制体制建设、业务流程设计、智慧公厕系统建设、网络建设、主机和储存平台需求、平台运维管理体系、硬件标准规范体系以及考核评价体系等多个方面。其中，智慧公厕系统建设尤为关键，它能实时监控公厕运行状态，保障公厕的清洁和正常运行。平台建设还充分利用了现有的电子政务网络资源，并考虑了有线和无线网络的需求。在功能上，平台通过普查、整合等手段全面收集环卫车辆、企业、人员、设施、设备等数据，建立智慧环卫基础数据库。利用智能传感、卫星定位等技术实现环卫作业的在线监管和远程监控，实现对道路、公共场所等的作业状况和卫生状况的全面监管。此外，平台还建立了环卫作业网格化管理责任机制，实现从作业过程到结果的全面监管，科学评价区域、部门、单位和人员的作业效果。 三、智慧环卫管理平台的效益与风险规避 智慧环卫管理平台的建设将带来显著的环境、经济和管理效益。环境方面，它将有力推进环境卫生监管服务工作，改善环境卫生状况，为人民群众创造更加清洁、卫生的工作和生活环境。经济方面，通过智慧化监管，大大降低了传统管理手段的成本，提高了监管的准确性和效率。管理方面，平台能够追踪溯源市民反映的问题，如公厕异味、渣土车辆抛洒等，并找到相应的责任单位进行处置，防止类似事件再次发生。同时，平台还拥有强大的预警机制功能，能够在很多环卫问题尚未出现前进行处置。然而，平台建设也面临一定的风险，如部门协调、配合问题，建设单位选择风险以及不可预测的自然灾害等。为了规避这些风险，需要加强领导、统一思想，选择优秀的系统集成商承接项目建设，并做好计算机和应用系统的培训工作。同时，也要注意标准制定工作和相关法律法规的制定工作，以保证系统建设完成后能够真正为环卫管理工作带来便利。

  • apache-parent-10-14.el7.x64-86.rpm.tar.gz

    1、文件内容：apache-parent-10-14.el7.rpm以及相关依赖 2、文件形式：tar.gz压缩包 3、安装指令： #Step1、解压 tar -zxvf /mnt/data/output/apache-parent-10-14.el7.tar.gz #Step2、进入解压后的目录，执行安装 sudo rpm -ivh *.rpm 4、安装指导：私信博主，全程指导安装

  • 用于卫星通信的CTS天线

    用于卫星通信的圆极化CTS天线研究

  • 人事档案登记及查询系统.xlsx

    人事档案登记及查询系统

  • 12 -防损部经理绩效考核表1.xlsx

    12 -防损部经理绩效考核表1

  • 泰尔指数模型stata全流程代码+数据+文献(数据权威)

    ## 一、泰尔指数模型stata全流程代码+数据+文献 参考C刊《农业经济问题》朱红根（2023）老师的做法，用泰尔指数是衡量个人或地区之间收入差距的重要指标，本文利用泰尔指数分析中国区域内和区域间数字乡村发展水平的差异，测算了全国总体差异、区域内差异、区域间差异以及相关贡献率。此资料包括stata全流程代码、案例数据、参考文献，用excel计算有标注有过程 ，并且参照文献讲的。 ## 二、2005-2021年城乡收入差距与泰尔指数：原始数据+测算结果 泰尔熵标准(Theil’s entropy measure)或者泰尔指数（Theil index）是衡量个人之间或者地区间收入差距（或者称不平等度）的指标。又称泰尔系数或锡尔指数，但我还是习惯叫泰尔指数。Theil指数用来表示区域经济差异状况，数值越大则差异程度越大。 数据名称：城乡收入差距与泰尔指数（原始数据+测算） 数据年份：2005-2021年 指标变量：泰尔指数、城镇收入占农村收入之比、城镇居民人均可支配收入、农村居民人均可支配收入、乡村人口、全体居民人均可支配收入、城镇人口、年末常住人口 测算公式：

  • 34 -配送部经理绩效考核表1.xlsx

    34 -配送部经理绩效考核表1

Global site tag (gtag.js) - Google Analytics