分布式系统sap原则的简单介绍

仓库管理和SAP系统如何使用

简单来讲SAP系统提供的仓库管理功能有：收、发、转、盘点四大项。其中，‘收’就是收货入库，除系统标准的收货、退货外，还可以依实际需要增设超交收货、折补收货、免费收货等；

创新互联专注为客户提供全方位的互联网综合服务，包含不限于做网站、成都网站制作、呼图壁网络推广、成都微信小程序、呼图壁网络营销、呼图壁企业策划、呼图壁品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联为所有大学生创业者提供呼图壁建站搭建服务，24小时服务热线：028-86922220，官方网址：www.cdcxhl.com

登录

选择所需要管理的部门

选择收、发、转、盘

检查

确认

退出

可以根据如下仓库管理指导学习：百度文库-ERP系统

拓展资料：

储存原则

1.存储规定

a）防火、防水、防压、防潮；

b）定点、定位、定容、定量；

c）先进先出

2.物料存储要分门别类，按“先进先出”原则堆放物料，填写《物料标识卡》等标识，尾数应贴上“尾数标签”或做好尾数标识，并有相应的台账、卡账以供查询；

3.对因有批次规定、色别规定等特殊原因而不能混放的同一物料应分开摆放；

4.物料储存要尽量做到“上小下大，上轻下重，不超安全高度”

料不得直接置于地上，必要时加垫板、纸皮或置于容器内，予以保护存放；

5.任何物料不得堆放在仓库通道上，以免影响物料的收发

仓库管理-百度百科

分布式理论基础之BASE原则

BASE理论是由eBay架构师提出的，是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于CAP定律逐步演化而来。其核心思想是： 即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性) 三个短语的缩写。

参考文章：

分布式系列文章——从ACID到CAP/BASE

分布式理论(二) - BASE理论

分布式系统一致性高可用的解决方案总结

本文基于对redis、zookpeer、rocketmq、elasticsearch学习总结，对于分布式系统学习，一定绕不开一个点，那就是CAP定理。什么是CAP定理，我这里简单的复制摘抄一下百度上的文案。

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

说明一下上面的三个要素各代表的含义：

CAP定理说明上述的三个要素不能兼顾，最多只能满足其中的两个要素，在分布式系统中，一般都是保证分区容错性，而在一致性和可用性之间做取舍。因此存在CP、AP两种分布式集群的实现。

CP集群，即满足一致性和分区容错性，如zookpeer

AP集群，即满足可用性和分区容错性，如redis-cluster

下面，针对与上述的CP和AP问题，我们展开话题。

对于分布式系统，学习了解多了之后，发现其内在的解决方案基本上都是一样的，所谓万变不离其中。总结一下大体在于以下几步：

数据分片，很多分布式系统尤其是中间件服务，一般都会涉及高并发，数据量大的问题，如redis-cluster、recketmq，以及被大家熟知的Elasticsearch。针对于大数据量高并发的问题，若不做处理，服务器的性能将会成为服务的瓶颈，解决的方案之一便是数据分片，将大数据量在集群中按照一定的规则分片，使数据按照一定的规则分布集群的不同服务器上，以减轻单个服务器的压力，保证服务集群的可用性。

redis-cluster的数据分片是通过redis-cluster的哈希槽来实现的，redis-cluster有16384个哈希槽，这个数量是固定的，根据集群中服务器的数量可以手动的调配每个服务上存放的hash槽的数量，哈希槽之间是相互独立的，因此对集群的扩展提供了便利。

rocketmq的分片和topic紧密相关，在使用rocketmq中，无论是消息的生产者还是消费者都需要注册订阅一个topic。在rocketmq集群中，集群中的broker保存这个topic下数据的一部分，也就是topic的其中一个数据分片。当然，rocketmq不仅将一个topic下的数据分片到多个broker上，而且，一个broker上的topic数据还可以被分为多个queue，这是因为rocketmq中，一个queue只能被一个consumer消费，若是consumer的数量多于queue的数量，没有绑定queue的consumer将不能消费数据。

elasticsearch的数据分片在我看来和mysql的分库分表原理是一样的，elasticsearch中，每一个索引都相当于mysql的一个表，将一个索引分成多个shard放在不同的节点上，每个shard存储一部分数据。elasticsearch将数据进行分片，这样可以支持集群的横向扩展，同时，多个节点提供服务可以提高系统的效率和吞吐量。

综上所述，数据分片的一般都有两个好处，一个是支持集群的横向扩展，而是提升服务的吞吐量和性能。数据分片解决了以上两个问题，但是若是集群中一个节点发生宕机，或者因为网络原因和集群断开链接，那么这部分的数据分片甚至整个集群都会不可用，如何解决这个问题，就需要用到数据备份和主备切换。

数据分片的策略 了解了数据分片之后，需要了解以下数据分片的策略，根据集群提供服务的性质不同，可以采用的数据分片策略也各有不同，下面是我学习后的总结：

说到这里，会发现其实这种分片策略和负载均衡的策略还是挺相似的。

数据备份，举个例子来说，我有两台电脑A、电脑B，A用于工作，B用于游戏，我写了一篇文章，保存在电脑上电脑上，若是某一天我的电脑A磁盘坏了，那我这篇文章就找不到了，即便我现在还有电脑B，我也没有办法在对文章进行编辑。但是若是我在之前，就将文章拷贝了一份放在电脑B上，那么现在，我用电脑B就可以对文件进行编辑修改。

举这个例子，我的目的就是为了说明数据备份对于集群可用性的意义，例子中，我的两台电脑可以认为是集群中两台服务器，两台服务器一开始提供的服务可能不相同，A电脑提供的就是编辑文章的服务，数据备份的意义就在于，当原本提供服务的服务器宕机损坏，集群中另外的服务器仍然可以根据已经备份的数据提供相同的服务，而不会影响到用户的工作。

数据备份的目的就是不发生单点问题的措施之一，但是若是数据备份的策略不合适，备份的时机不对，那么备份的数据时效性也是问题。还是从例子出发，这里的文章每次都是我手动从A电脑拷贝到B电脑，这是我的备份策略，若是我选择每天晚上才拷贝一次，那么若是A电脑在我拷贝之前坏了，当天的文章编辑数据就丢失了，采用手动的方式备份，这种备份方式耗时耗力且不可控，而在分布式集群中，不同的系统采用了不同的备份策略，下面一一来说明。

首先明确一点，在分布式集群中，不可能采用人工手动备份，一定是系统程序按照一定的规则自动备份，就好像我将AB连在一起，写个程序，让A电脑自动把文章同步到B电脑。数据备份的方式分为两种：

这里以redis-cluster和zookeeper举例。

在redis-cluster中，当一台新的slave节点加入时，会出发数据同步，需要将主节点的数据同步到从节点。这时根据从节点的状态有两种同步方案：完整重同步 和 部分重同步

完整重同步既是将主节点的全部数据都复制给新的slave节点。大致流程为，当一个新的节点加入进来时，发送PSYNC命令给主节点并携带slave节点自身的信息（重点是复制偏移量），主节点会根据slave传过来的信息判断是完整重同步还是部分重同步，如何判断与数据同步时的复制缓冲区有关，更细节不展开介绍。

相对于redis-cluster，zookeeper中的数据同步有四种方式，和redis-cluster完整重同步和部分重同步相似的SNAP（全量同步）和DIFF（增量同步），以及zk事务处理相关的TRUNC（仅回滚同步）、TRUNC+DIFF（回滚+增量同步）

当节点已经加入集群，成为集群中的从节点，只要不断开连接，一般都只需要进行增量同步，不过系统同步的范围和方式有所差异，大致分为下面六种：

下面还是以具体服务来举例： redis-cluster中，主从复制采用的是异步复制的方式，master节点在做数据变更之后，会由一个异步线程将数据变更同步给slave节点，这是通过push的方式。当redis2.8之后，slave会周期的获取最新的数据，加入了pull方式。无论是master还是slave，在进行数据同步时，不会阻塞正常的应用请求。所以redis-cluster的主从复制，是异步备份+最终一致性的备份。

elasticsearch的主从复制可以手动设置同步备份或者异步备份，数据备份时不要求强一致性，而是主分片（primary shard）会维护一份需要同步的（replica shard）分片列表，这个分片列表同步完成，则认为数据备份完成，需要注意的是，这里的主从复制不是节点的更新数据，而是分片的更新数据。

rocketmq的主从复制和elasticsearch类似，也可以分为同步备份和异步备份，不同的是rocketetmq的数据备份采用的是pull的方式，从节点会通过HAConnection链接主动向主节点发送待拉取数据偏移量，待主节点返回节点更新数据信息，更新从节点数据偏移量，如此重复。

zookeeper的数据备份则是通过ZAB协议，通过消息广播的方式同步数据到从节点。

当数据备份后，主从节点上就有了相同的数据，为了提升服务的性能，那么可以采用读写分离的方式。主节点提供数据写服务，从节点提供读服务，可以有效的分担主节点的服务器压力。可以进行数据分片的系统，如：redis、rocketmq、elasticsearch，一般都可以配置一主多从、多主多从的集群架构。

读写分离之后，主节点提供写服务，从节点只提供读服务，因此若是主节点发生宕机，从节点依然可以提供读服务，但是服务无法更新数据，这时候就要进行主从切换。早起，主从切换可以由人工手动完成，不过随着技术发展，主从切换已经成为集群的必备功能。想要实现主从切换，必须要解决两个问题：

解决这个问题，需要额外再引入一个角色，相当于是一个监视者的角色，能够长期的对主节点进行监视，若是只有一个监视者，可能会发生误判，所以还需要一套机制去保证当监视者说主节点宕机，那么主节点是真的宕机，否则集群会出现脑裂问题。

以redis为例，在redis的哨兵模式中，这个监视者的角色是一个个哨兵实例，而在redis-cluster架构中，这个监视者的角色是redis实例自己。

在redis哨兵模式中，哨兵集群中的哨兵实例会定期和redis实例进行通信（ping），监视redis实例的在线情况，若是其中一台哨兵发现redis实例master故障，那么该哨兵会将该master状态改为主观下线，并通知其他哨兵，当哨兵集群中达到配置数量的哨兵实例认为该master都为主观下线状态，这时会将master修改为客观下线状态，并开始触发后续的故障转移。

在redis-cluster模式中，集群中的每一个节点都可以和其他节点通讯（ping），当某一个节点A发现主节点B下线了，A会将该主节点B设为疑似下线状态。集群中的节点会通过互发消息维护信息，当另一个节点C收到A的消息时，会将A对B节点的判断记录在C节点的维护信息下，这个信息可以理解为A说C疑似下线了。若是有其他节点发送C的状态信息，A同样也会记录。当某一个节点如C发现记录的B节点信息中，超过半数的主节点都认为B下线了，那么C就会将B节点状态修改为已下线状态，并广播消息给集群的其他节点，开始后续的故障转移。

上面就是redis的两种分布式模式故障检测的方案。大致可以归结为，监视节点会和被监视节点进行通讯，感知被监视节点的状态；监视节点之间也会进行通讯，同步信息。为了防止集群出现脑裂，对于某个主节点的故障判断会十分的谨慎，需要达到一定数量的监视节点都认为主节点故障时，才会认为主节点真的故障，从而触发故障转移。

在rocketmq集群模式中，nameserver扮演着监视者的角色（不同于其他系统，nameserver并不负责集群的主从切换，rocketmq 4.5之前不支持自动主从切换，4.5之后，通过dledger实现自动的故障转移）。在elasticsearch集群中，elasticsearch实例本身在扮演监视者角色。zookeeper也是实例本身扮演监视者的角色。

故障转移就是当集群发现集群中的主节点/从节点发生故障之后的处理，从节点比较简单，直接将从节点下线即可，主节点的故障转移流程比较复杂，各个系统根据系统的功能和架构有不同的实现方式，共同点是选举出的主节点一定是集群中数据最新的最完善的节点。

选举过程大致如下：

首先选举成功的条件时集群中具有投票权限的超过半数的节点投票一致，通过某一个节点成为主节点。

开始一轮选举时，定义为一个纪元，用一个自增的id表示。

候选节点将带着纪元id，以及自身信息作为投票申请广播给集群给可投票的节点。

具有投票权限的节点投票只要满足两个条件：1.自身在最新纪元没有给投过票 2.节点发送过来的投票申请时最新纪元的（如何判断时最新纪元，则是判断一下节点之前通过申请的纪元id是否小于当前申请的纪元id）。

半数以上的投票节点通过某一个候选节点成为leader节点，则leader产生。

若是一个纪元没有产生主节点，则候选节点进入随机的休眠，并且开启下一个纪元，知道产生leader节点。

在zk集群经过崩溃恢复模式之后，需要保证：1.已经提交的事务不能丢失 2.未被提交的事务不能出现。如何保证以上两点，zk服务集群中维护了zxid，zxid也可以看作是一个自增的id，集群中每产生一个新事物，zxid就会增加。zxid有64位，前32位维护了集群主节点变更情况，每重新选举出一个新的主节点则增加，后32位维护在新的主节点集群下事务的id，产生一个新事物则增加。

ZAB的选举模式有很多种，我主要了解了默认，也是推荐的FastLeaderElection模式，在这个模式下，我会以集群中一台参与选举的服务器的视角来模拟选主的过程；

我是一台zk服务器，我现在很慌，因为我的leader服务器不见了，作为一个有梦想的follower，我也要参加leader的选举，为了这次选举我要准备：myid(在集群中标识是这台服务器的id)，zxid(本台服务器保存的最新事务id)，logicClock(本台服务器发起的第几轮投票)

首先我会自己选自己，这得自信。于是我将自身的选举信息[myid, zxid]放到自己的收票箱，然后将我的选举信息还有我的选举轮次logicClock广播给其他服务器进行PK

作为一个有原则的服务器，我们的选举也是有原则的，当我收到别人的选举信息时，我也会将他和我自己的选举信息进行PK，PK的原则如下：

经过这一系列的PK，终于选出了我心中的leader服务器，要广播给其他服务器。

超过半数的服务器都同意某一台服务器成为leader，选举结束了。

SAP系统是什么

SAP起源于Systems Application, Products in DATA processing. SAP既是公司名称,又是其ERP (Enterprise-wide Resource Planning)软件名称。

SAP是国际上著名的标准应用软件公司。SAP总部设在德国南部的沃尔道夫市，公司成立于1972年，1988年成为德国股票上市公司。到1995年底，SAP在世界40多个国家和地区设有代表处和独立子公司，具有近5000家用户，成为世界第五大软件供应商。1995年SAP集团在中国设立了子公司。

SAP的一整套程序是针对所有企业的一种数据和应用集成方法，它将业务和技术进步融入了一个综合性的高品位的标准系统，即商品化软件系统。SAP的主打产品R/3是用于分布式客户机/服务器环境的标准ERP软件，主要功能模块包括：销售和分销、物料管理、生产计划、质量管理、工厂维修、人力资源、工业方案、办公室和通信、项目系统、资产管理、控制、财务会计。R/3适用的服务器平台是：Novell、Netware、NT Server、OS400、Unix ，适用的数据库平台是：IBM DB2、Informix、MS SQL Server、Oracle ，支持的生产经营类型是：按定单生产、批量生产、合同生产、离散型、复杂设计生产、按库存生产、流程型，其用户主要分布在航空航天、汽车、化工、消费品、电器设备、电子、食品饮料等行业。

2.2 SAP公司的软件

R/2和R/3系统是德国SAP公司所提供的MRP II产品。R/2是用于集中式大型机环境的系统，R/3是用于分布式 的客户机/服务器环境的系统。

2.3 R/2和R/3系统的共同特点如下：

（l）综合完善功能：系统提供的应用功能有：会计、后勤、人力资源管理、办公室和通信等。它涉及各种管理业务，覆盖了管理信息系统中各种功能。

（2）高度集成模块：系统具有一个高度集成化的结构，表现在它所提供的各种管理业务功能之间都是相互关联的，各模块输入输出相互衔接，数据高度共享，任何数据的修改都将会引起相关数据自动修改。

（3）适应多种行业：系统是一个能够适用于多种行业应用的软件，它是通过标准核心软件与不同行业特点相结合而产生的。应用领域主要是各种制造业，此外，在零售公司、公共设施、银行、医院、金融和保险也有应用。

（4）开放应用环境系统是一个开放式软件系统，它可以运行在所有主要硬件平台和操作系统之上和不同数据库，有HP－Unix操作系统，IBM的AS/400操作系统，Windows NT，Oracle数据库，Informix数据库等，以及在Sequent和Compaq计算机上同时运行Unix和Windows NT的Server的平台。

2.4 点评：

R/3的功能涵盖了企业管理业务的各个方面，这些功能模块服务于各个不同的企业管理领域。在每个管理领域，R/3又提供进一步细分的单一功能子模块，例如财务会计模块包括总账、应收账、应付账、财务控制、金融投资、报表合并、基金管理等子模块。SAP所提供的是一个有效的标准而又全面的ERP软件，同时软件模块化结构保证了数据单独处理的特殊方案需求。

目前，排名世界500强的企业，有一半以上使用的是SAP 的软件产品。因R/3的功能比较丰富，各模块之的关联性非常强，所以不仅价格偏高，而且实施难度也高于其他同类软件。R/3适用于那些管理基础较好经营规模较大的企业，普通企业选择R/3时，要充分考虑软件适用性和价格因素，中小型企业则可选择SAP Business One，简称SBO。介绍如下。

3．SBO介绍

3.1 什么是SBO?

SAP Business One是专为小型企业设计的企业管理信息系统软件

SAP Business One -- 这套操作简单但功能强大的解决方案能够满足客户标准的业务需求，它涵盖财务、物流、销售自动化以及其他功能。它专为小型企业设计，这些企业需要在IT解决方案中得到相对简单的，具有特定行业需求的功能。

SAP Business One能够优化企业的各个方面，从财务会计到制造直到销售与服务。它还提供真正的创新特性，包括自动物料要求规划的五步 MRP 向导，以及允许用户通过一步鼠标点击操作将不同信息片段链接在一起的 DragRelate 工具。

3.2 SBO业务管理

财务 -- 处理所有财务交易，包括总分类帐、科目设置和维护、日记帐分录、汇兑损益调整、预算定义、成本中心设置、成本分配规则等。

财务功能提供的工具和报告用于管理所有的财务流程，包括:

会计科目表

日记帐分录

过帐模板

汇率差异

周期性过帐

冲销事务

资产负债表

定义利润中心

预算

财务报表模板

定义分配规则

利润中心和分配规则表

银行交易 -- 处理所有收付款相关业务，例如现金收款，开具支票，存款，信用卡付款以及银行对帐。

银行交易旨在利用以下工具帮您处理所有财务事项:

收款

支票

信用卡管理

付款向导

银行对帐和核销

对帐向导

销售与应收帐款 -- 创建报价，输入客户订单，设置交付日期，更新库存余额，并管理所有发票和应收帐款。

从报价到开具发票和付款，销售和经销功能将帮您利用以下工具和能力完成整个销售流程:

报价单

订单

交货

退货

应收发票

应收发票和付款

应收贷项凭证

单据打印

自动汇总向导

催款向导

采购/应付帐款 -- 管理和维护供应商合同和交易，例如签发采购单，更新库存数量，计算进口商品的到岸成本价值，处理退货以及红字发票。

采购功能用于管理和维护您与供应商关系的各个方面。这一功能提供的工具和流程包括:

采购订单

收货采购订单

采购退货

应付发票

应付贷项凭证

到岸成本

单据打印

客户关系管理

销售机会业务伙伴 -- 维护客户、分销商和供应商的所有信息 ，包括客户档案、相关业务交易，以及帐户余额，并可管理与该客户相关的活动日程表。

服务 -- 挖掘服务部门的潜力，对服务部门的运作、服务管理、服务计划提供支持，跟踪客户交流活动和客户支持。提供的知识库可帮助技术人员研究或解决问题。