13518219792
1. 性能和时延问题 在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较校服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗： 1） 客户端需要对消息进行序列化，主要占用CPU计算资源。
创新互联公司专注于企业成都营销网站建设、网站重做改版、围场网站定制设计、自适应品牌网站建设、H5网站设计、商城系统网站开发、集团公司官网建设、成都外贸网站建设公司、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为围场等各大城市提供网站开发制作服务。
php的在页面载入时或调用session_start()时从数据源中读取session数据到$_SESSION变量。
当页面执行完毕或调用session_write_close()时把$_SESSION变量写入数据源。
php默认的session.save_handler=files，可以通过文件锁来实现读写同步，保证session数据的一致性，不会产生问题。然而当使用sqlite作为session handler时，由于没有同步机制，会产生bug。如下代码：
test1.php
PHP code?
session_start();
$_SESSION['data1'] = 'data1';
sleep(10);
session_write_close();
test2.php
PHP code?
session_start();
$_SESSION['data2'] = 'data2';
session_write_close();
在同一浏览器进程里（保证使用相同的session_id），先访问test1.php，再访问test2.php，会发现data2根本没有写入sqlite数据库中。session.save_handler=memcache还没有测试，估计也有这个问题。如果采用默认的files handler会发现test2.php的请求会被挂起直至test1.php执行完毕，这就是文件锁同步机制造成的。
我想到了两种解决方案：
1、实现互斥锁，保证同一session_id访问session数据是同步的，这样会产生一个阻塞的问题（php默认的session实现也会有这个问题）。
2、写入session数据时进行数据合并，不过这样仍然不能完全保证数据一致性。
不会，这里的原子性不要从php的角度看，应该从redis的角度看，同一个redis节点对并发的请求都是序列化处理的，所以单操作不存在你担心的并发问题，但如果是read write的形式到哪里都不行了，切记。
有人问到read write是啥，其实就是并发的一个经典问题，代码如下
$v = $redisClient-get('v');
$v ++;
$redisClient-set('v', $v);
就是先读取数据，再修改数据，在写回修改，这里是希望每次访问都递增v的值，但在并发情况下，两个进程都读取到了一样的初始值，比如3，然后都加1变为4，最后把4写回Redis，这种情况就会统计数据比实际的少。尽量都用Redis的原子操作就好，比如incr。
微服务架构的流行源于它能够带来更快的变化响应能力，比如独立部署，每个服务的能力职责是独立的，可以按需独立发布；再比如每个服务可以由不同的开发团队负责，每个服务的技术栈也可以不同，可以选择更快捷合理的方式实现不同的服务。
然而，微服务架构作为分布式架构，躲不开的一个问题就是数据一致性的问题，特别是在技术异构和数据源类型不同的情况下，传统的分布式事务（2PC或3PC）也很难解决微服务架构下的一致性问题。
在微服务架构下，多个服务之间通常会定义明确上下游关系，下游系统可以依赖上游系统，下游系统可以通过API查询或修改上游系统的数据；反过来则不然，上游系统不应该知道下游系统的存在，也就是说上游系统不能依赖下游系统，上游系统的变化只能通过异步事件的方式发出，下游系统监听事件并基于事件做对应的数据状态变化。
在基于上面原则的微服务架构下（见上面图示，本文不考虑服务间循环依赖的场景），在上下游服务间的数据通信（图示中的每个箭头表示一种数据通信）一旦发生问题，都会产生数据不一致的场景，下面我们逐一说明：
举个例子，订单服务是下游服务，库存服务是上游服务，在订单确认时要锁定库存，实现上订单服务在状态变化同时通过同步API修改库存的状态，为了保证数据一致性，在调用库存服务API异常后订单服务会回滚当前的数据状态变更。
在这个场景下，同一个业务流程，需要同时修改两个服务的数据，在以下两种情况下会发生数据不一致的问题：
上游服务每个关键状态变更都可能触发下游服务的一些逻辑链，因此上游服务发布的事件对于下游服务是非常重要的，但这些事件并不影响上游服务自身逻辑，也不影响自身数据状态的变化，因此通常不会设计成阻碍业务流程，那么在事件服务或事件载体（通常是消息队列）与上游服务之间的通信异常，就会导致上游服务的事件发布失败。
这种场景下，上游服务的业务流程已经成功，不可能有再次触发事件的场景，这个事件就丢失了，下游服务因为没有收到上游服务的事件，数据没有做对应的变化而导致数据一致性问题。
同样，下游服务在消费事件时也很有可能因为一些原因，导致事件的消费失败，这些原因可能包括：
上游服务并不关心下游的消费者，所以对于发布出去的事件，上游系统也不关心下游服务是否消费成功，更不会有因某个下游服务消费失败而重发事件的逻辑，这同样会导致类似于场景二的数据一致性问题。
根据CAP理论，分区容错性、可用性和一致性里面必须要牺牲掉一个，而在实际实现过程中，分区容错性和可用性是很难舍弃的，所以通常会舍弃一致性，取而代之会用最终一致性保证数据在可容忍的时长内达到最终一致。
微服务架构也不例外，在服务内部，可以通过本地事务保证数据的强一致性；而当业务发生在多个服务中，我们追求最终一致性。那么都有哪些措施可以保证跨服务的最终一致性呢？
这是个业务问题，在微服务的架构下，每个服务都是独立的，如果有一个业务功能需要同时修改两个服务的数据，往往这个业务可以拆分成两个步骤，比如场景一种提到的订单和库存的例子，如果我们可以先锁定库存，然后再确认订单看上去这个问题就迎刃而解了。
因此在业务中发现一个功能需要同时修改两个服务的数据，我们首先可以来讨论这个业务设计是否合理；如果业务上很多场景都要求两个服务的数据保持强一致，那可能我们需要看看微服务的划分是否合理。
为了解决场景二和场景三的不一致性问题，需要上游服务和下游服务的共同努力：
上游服务需要尽可能将事件发送出去，比如：先同步发送，如果失败改为异步重试，重试多次仍然失败可以先持久化，通过定时任务来重发或者人工干预重发。
下游服务也要尽可能的把事件处理掉，收到事件后可以考虑先将事件持久化，消费成功后标记事件，如果消费失败可以通过定时任务重试消费。
当我们提到重试，就不得不考虑幂等性的问题，这里的幂等性包括以下两个场景：
即便我们做了很多我们认为万全的准备，在分布式系统的执行链路上，每个节点都有可能失败，加上业务的复杂度，数据不一致的情景也很难彻底解决，而对于那些小概率发生但技术解决起来成本昂贵的问题，我们可以尝试通过对业务的深刻理解设计一些后台的数据维护功能，保证在核心业务数据异常时，可以在一定的规则内进行修复，从而保证业务的顺利进行
数据一致性问题首先是个业务问题，其次才是个技术问题。在微服务架构下，我们期望每个服务职责单一，这种职责单一体现的是业务价值，如果微服务的拆分过小而导致业务难以实现，那这种拆分是不合理的，业务专家们非常有必要了解系统，从业务侧给出服务拆分的建议。
在数据一致性问题上，我们首先要思考业务设计的合理性，其次是当前架构设计的合理性，然后在一定的约束下，通过最终一致性保证业务价值，除非迫不得已，不建议引入分布式事务框架，一方面成本较高，另一方面也会引入性能等新的问题。
