数据一致性，什么是多副本数据的强一致性？
一致性又可以分为强一致性与弱一致性。强一致性可以理解为在任意时刻，所有节点中的数据是一样的。同一时间点，你在节点A中获取到key1的值与在节点B中获取到key1的值应该都是一样的。弱一致性包含很多种不同的实现，目前分布式系统中广泛实现的是最终一致性。所谓最终一致性，就是不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。也可以简单的理解为在一段时间后，节点间的数据会最终达到一致状态。对于最终一致性最好的例子就是DNS系统，由于DNS多级缓存的实现，所以修改DNS记录后不会在全球所有DNS服务节点生效，需要等待DNS服务器缓存过期后向源服务器更新新的记录才能实现。类似的，还有一些其它的弱一致性实现，下面摘自《NoSQL数据库笔谈》
https://docs.google.com/View?id=dc23x53c_64db5px4f6
redis为什么不能保证数据一致性？
redis要做到高可用，不能是单机部署，必须设计成集群架构，redis集群部署有哨兵sentinel模式，有主从模式和cluster集群三种，集群就必然面对数据同步问题，主从复制时间差和未及时同步到其它节点可能会造成数据不一致。
Kafka是如何保证数据可靠性和一致性？
什么是可靠性
对于消息系统来说，所谓可靠性就是指消息可以从生产者（producer）准确的送达到消费者（consumer）。可靠性保证有三个层次：
At most once 最多一次。消息可能会丢失，但是决不重复。At least once 至少一次。消息决不丢失，但可能会重复。Exactly once 恰好一次。这是最完美的，既不丢失，也不重复。如果要可靠的准确的传达消息，需要生产者程序，消息系统和消费者程序相互合作。
什么是一致性对于消息系统来说，一致性是指，如果一个消费者c1读到消息m1的offset是x，那么之后的任何消费者读到的offset是x的消息一定也是c1。
可以参看我的一个视频《分布式系统中的强一致性和弱一致性》
Kafka如何保证可靠性和一致性如果要可靠的准确的传达消息，需要生产者程序，消息系统和消费者程序相互合作。
生产者程序 Producer
生产者需要确认消息成功送达kafka的服务区broker，并且得到broker的返回消息，确认消息已经提交（commit）。如果没有成功返回需要重发，直到发送成功。
详细的配置解释，可以参考我的头条文章《Kafka的可靠性保证 - 生产者的配置》
Kafka服务器集群 Cluster
Kafka的服务器是一个集群，集群中至少需要包含3个以上的节点。通过主从备份可以保证不丢消息。只要提交的消息就保证不丢。
详细的配置解释，可以参考我的头条文章《Kafka的一致性保证》
消费者程序 Consumer
消费者从Kafka读取消息以后要妥善处理。所谓妥善处理，就是完成自己获取这一条消息的目标，比如生成一条业务数据存入数据库，或者发送消息到其他的系统。
消费者需要准确的维护offset，也就是消费到哪一条消息了。如果维护不好，就会导致丢消息或者重复消费。可以参考我的头条动画视频《[动画] 如何设计可靠的Kafka的消费者程序 - exactly once》。
详细的配置解释，可以参考我的头条文章《Kafka的可靠性保证 - 消费者的配置》
本人，@小马过河Vizit，专注于分布式系统原理和实践分享。希望利用动画生动而又准确的演示抽象的原理。欢迎关注。
关于我的名字。小马过河Vizit，意为凡事像小马过河一样，需要自己亲自尝试，探索才能获得乐趣和新知。Vizit是指Visualize it的缩写。一图胜千言，希望可以利用动画来可视化一些抽象的原理。
如何保证本地缓存分布式缓存数据库之间的数据一致性？
在现在的系统架构中，缓存的地位可以说是非常高的。因为在互联网的时代，请求的并发量可能会非常高，但是关系型数据库对于高并发的处理能力并不是非常强，而缓存由于是在内存中处理，并不需要磁盘的IO，所以非常适合于高并发的处理，也就成为了各个系统中必不可少的一部分了。
不过，由此产生的问题也是非常多的，其中一个就是如何保证数据库和缓存之间的数据一致性。
由于数据库的操作和缓存的操作不可能在一个事务中，也就势必会出现数据库写入失败，缓存不能更新，缓存写入失败的补偿机制。具体我们应该怎么做呢？
我们先看一个最常见的读缓存的例子在读取缓存的方式中，上图这种方式可以说是最为广泛使用的了。读本身是没有什么问题的，但是，写入缓存的方式，就是保证数据一致性的重中之重了。
这里我们不考虑定时刷新缓存的方式，也就是下面这类方式：
写入数据库和写入缓存是独立的，写入数据库操作后，需要等待定时服务执行，执行完成后缓存数据才会刷新。
这种方式会导致数据的不一致时间较长，数据刷新时，不管有没有改变的数据，都会重新加载，效率差。当然，并不是说这种方式就没用，还是有一些场景是可以使用的，例如一些系统配置的缓存，而且，这样做缓存刷新，代码量非常少，也便于维护。
我们今天只考虑双写的数据一致性如何来考虑。由于不同的写入方式，可能带来的结果也就是不同的。通常情况下，我们都有哪些写入数据并刷新缓存的方式呢？
方法一、先更新数据库，在更新缓存这套方案是最简单的一种缓存双写方案，我们先来看看流程图
使用这种双写的方案，只要在数据成功写入数据库后，刷新缓存就可以了，代码简单，维护也很简单。但是，简单的前提下，带来的问题也是很直接的。
首先，线程数据安全无法保证
例如：我们现在同时有两个请求会操作同一条数据，一个是请求A，一个是请求B。请求A需要先执行，请求B后执行，那么数据库的记录就是请求B执行后的记录。
但是，由于一些网络原因或者其他情况，最终执行的顺序可能就变成了：
请求A Update 数据库 -> 请求B Update 数据库 -> 请求B Update 缓存 -> 请求A Update 缓存。这样的结果会导致：
1. 数据库和缓存中的数据不一致，从而缓存中的数据就成为了脏数据。
2. 写入操作多于读操作，就会频繁的刷新缓存，但是这些数据根本没有被读过。这样就会浪费服务器的资源。
因此，这种双写方式很难保证数据一致性，不建议使用。
方法二、先删除缓存再更新数据库由于上述方式存在的问题，那么我们就考虑，能不能先删除缓存，在更新数据库，这样，在更新数据库的前后，由于缓存中没有数据了，请求就会穿透到数据库直接读取数据然后放入缓存，这样，缓存就不会被频繁的刷新了。
于是，我们就设置了一个新的执行顺序：
不过，这样一来，新问题又出现了。有两个请求，一个请求A，一个请求B，请求A去写数据，请求B去读数据。当并发量高的时候，就会出现以下情况：
请求A进行写操作，删除缓存 -> 请求B查询发现缓存不存在 -> 请求B去数据库查询得到旧值 -> 请求B将旧值写入缓存 -> 请求A将新值写入数据库这是，脏数据又出现了。如果我们没有设置缓存的过期时间，那么在下一次下入数据前，脏数据就会一直的存在。针对这种脏数据出现的情况，我们决定在写入数据后，增加一点延时，再删除一次数据，于是就有了方法三。
方法三、延时双删使用延时双删的策略，就能够很好的解决之前我们应该并发所引起的数据不一致的情况。那是不是延时双删就完全没有问题呢？不。
我们来假设一个场景，就是我们做了读写分离，那么使用延时双删可能问出现什么情况呢？
请求A进行写操作，删除缓存 -> 请求A将数据写入数据库了 -> 请求B查询缓存发现，缓存没有值 -> 请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值 -> 请求B将旧值写入缓存 -> 数据库完成主从同步，从库变为新值。
糟糕，又出现数据不一致了。
然后在看看性能如何，由于需要延时，如果是同步执行，性能必定很差，所以第二次删除只有做成异步，避免影响性能。那异步执行删除就会出现新问题，如果异步线程执行失败了，那么旧数据就不会被删除，数据不一致又出现了。
不行，我们需要向一个一劳永逸的办法，单纯的双删还是不可靠。
方法四、队列删除缓存我们在把数据更新到数据库后，把删除缓存的消息加入到队列中，如果队列执行失败，就再次加入到队列执行直到成功为止。
这样，我们就能够有效的保证数据库和缓存的数据一致性了，不管是读写分离还是其他情况，只要队列消息能够保证安全，那么缓存就一定会被刷新。
当然，根据这个方案，我们还可以进一步优化。因为这里我们的缓存刷新时基于业务代码的，也就是说，业务代码和缓存刷新的耦合度很高。有没有办法能够把缓存刷新独立出来，不基于业务代码执行呢？
方法五、binlog订阅删除缓存为了保证业务代码的独立性，我们可以通过订阅binlog日志的方式来刷新缓存。我们先启动mysql的binlog日志，然后如下图方式设计流程：
通过binlog的订阅，我们就把业务代码和缓存刷新的非业务代码独立开来。代码量小了，也方便维护了。程序员们也不需要去关心什么时候应该刷新缓存，是不是需要刷新缓存。
当然，实战中，我们还有很多不同的业务场景，可能需要的数据一致性同步方案也不同，这里也只算是一个案例。
yaahp层次分析法实验目的意义？
实验目的 1 . 掌握利用软件进行数学建模的基本思想. 2. 了解并学习层次分析法的基本思路与步骤. 3. 学习使用 yapph 这款专业层次分析法软件, 加深对 AHP 法的了 解和认识. ...
还没有评论，来说两句吧...