这是一个好问题！

这个问题叫做 vendor lock-in (

)。这应该不（仅）是技术上的问题，而（更）是经济学的问题。简单说就是一个厂商的消费者在不付出一定代价的情况下很难或几乎不可能转换到其他厂商去。最实际的例子就是不能携号转网的中国手机号码。

这个对用户来说会造成什么影响？很遗憾，现状就是用户可能要承受损失。事实上没错，这个问题是今天云存储技术备受指责的一个焦点。

（我知道这个概念是在研究云存储的时候，所以我这里讲一下云存储或者分布式存储里的这个问题和可能的解决方法，和题主说的软件、电子书不太一样。。）

举个例子说一下云存储里的这个vendor lock-in问题。比如说我现在有大量的数据（数十T假设）存在Amazon S3上，有一天Amazon突然宣布涨价，那我可能根本没有办法把这些数据以很小的代价转移到其他的服务提供商，只能认Amazon宰割。又或者某天Amazon干脆宣布关闭S3，那我的数据怎么办。

要解决这个问题，最基本的肯定是制度上的保证，比如规定在服务变更之前要提前通知啦，还有制定统一标准准保证不同服务商之间服务可以迁移之类的。但是即使这样，迁移几十T数据的代价还是太高了。

从技术上来说，最基本的想法自然是通过冗余到不同的提供商来保证可用性。

。。。但是重复购卖几份服务也是要花几份的钱的啊。。。

现在学术界主流的方法是采用

（擦除码）来将数据分散到不同的vendor上，这样可以容忍部分数据的丢失，只需要增加一小部分存储容量。

擦除码这个东西其实是很古老的东西，RAID6已经用了很多年了。简单说一个(k,n)模式的擦除码（n>k)可以从一份数据中生成n个1/k大小的数据片段，这些数据片段中的任意k个都可以完全还原原来的数据。也就是说，这个数据可以容忍n-k个数据段的丢失。（最常见的擦除码是Reed Solomon编码。）

用擦除码解决vendor lock-in的基本思路就是把数据分割成数块分别交给不同的provider去存。比如为了防止一个service provider撂挑子，可以通过(40,50)模式的擦除码从一个数据生成50个信息块，再存到5个不同的storage service上，每个存10个信息块（增加20%的费用），这样即使一个storage service不可用了，剩下的40个还是能恢复信息。（当然，实际的分配策略可能需要考虑不同service的可靠性可用性价格还有重新生成新片段的难度等等因素。）

不过很遗憾，原理是很简单，实际应用中还有很多问题需要研究。。。比如如何从云中快速重构数据，如何在丢失一部分数据块的情况下以最小的代价（如移动最少的数据啊之类的）生成出新的数据块以维护原有的可用性等等。。。。还能毕业好多phd。。。

嗯哼。。。

====

PS：

Facebook有打了erasure coding补丁的HDFS实现：

微软也有相关论文：