下学期导师接了一个973军工项目，会用到大数据处理、分布式存储等相关技术。总体来说，还是与自己之后想要从事的区块链领域有些相关性的，可以为自己之后的求职简历增加些相关项目经验。下面，我们来分析几个区块链工程师的任职要求，来看看相关性。

　　分析以上岗位，我们很容易发现，许多区块链开发工程师的应聘要求：对分布式数据库、分布式系统、分布式存储 熟悉并由相关经验者优先！

　　下面对相关概念进行下梳理：

--有序集合)和hash（哈希类型）。这些都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了这类key/value存储的不足，在部

　　这部分旨在简短的介绍K-V数据库，更详细的描述可以参考文章下方的引用部分。

　　K-V存储系统是最简单的数据库类型之一。几乎所有的编程语言都带有内置的K-V存储功能。比如C++中STL的map，Java的HashMap，Python的dictionary。K-V数据库通常包含下列接口：

• Set(key,value): 将"value"存储内存中，其标识符为"key"，以便我们之后可以用"key"来获取数据。如果在"key"下已经有数据了，那么原数据将被替换。

　　大多数底层的实现都使用了hash table或者是自平衡的树结构（比如B-Tree和红黑树）。有时候数据太大了无法放在内存中，或者为了防止宕机必须把数据持久化，这种情况下，就必须使用文件系统来存储。 

　　K-V数据库是NoSQL运动的一部分，它重组了没有完全使用关系数据库中概念的众多数据库， 总结了这些数据库的主要特点：

• 可能不对ACID规范提供完全支持
• 可能提供分布式，可容错的架构

K-V数据库和关系型数据库

　　不同于关系型数据库，K-V数据库并不清楚存储数据的值，而且也没有像MySQL和PostgreSQL中schema的概念。这也就意味着它不能像关系型数据库一样通过

使用带where的SQL语句来过滤并查询所存数据的部分内容。如果你不知道该从哪查询，你需要遍历所有的key值，找到对应的value，对其进行过滤，最终只保留你

想要的那部分数据。这样以来计算量会非常大，同时也意味着只有在key已知的情况下，K-V数据库才能保证高性能，否则其性能明显不足。（注：有一些K-V数据库

支持结构化存储，而且有域索引）因此，虽然在绝对访问速度方面K-V数据库优于关系型数据库，但需要已知key值的要求限制了其应用场景。

　　NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地

的运用，这一概念无疑是一种全新的思维的注入。

　　NoSQL，泛指非关系型的数据库。随着互联网网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。

虽然NoSQL的流行与火起来才短短几年的时间，但是不可否认，现在已经开始了第二代运动。尽管早期的堆栈代码只能算是一种实验，然而现在的系统已经更加的成熟、稳定。不过现在也面临着一个严酷的事实：技术越来越成熟——以至于原来很好的NoSQL数据存储不得不进行重写，也有少数人认为这就是所谓的2.0版本。该工具可以为大数据建立快速、可扩展的存储库。

NoSQL数据库的四大分类表格分析

内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。	数据无结构化，通常只被当作字符串或者二进制数据
以列簇式存储，将同一列数据存在一起	查找速度快，可扩展性强，更容易进行分布式扩展
Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）	数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构	查询性能不高，而且缺乏统一的查询语法。
社交网络，推荐系统等。专注于构建关系图谱	利用图结构相关算法。比如最短路径寻址，N度关系查找等	很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。

SPARK（计算引擎）

MapReduce所具有的优点；但不同于MapReduce的是——Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。

　　Spark 是一种与 Hadoop 相似的开源集群计算环境，但是两者之间还存在一些不同之处，这些有用的不同之处使 Spark 在某些工作负载方面表现得更加优越，换句话说，Spark 启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。

　　Spark 是在 Scala 语言中实现的，它将 Scala 用作其应用程序框架。与 Hadoop 不同，Spark 和 Scala 能够紧密集成，其中的 Scala 可以像操作本地集合对象一样轻松地操作分布式数据集。

尽管创建 Spark 是为了支持分布式数据集上的迭代作业，但是实际上它是对 Hadoop 的补充，可以在 Hadoop 文件系统中并行运行。通过名为 Mesos 的第三方集群框架可以支持此行为。Spark 由加州大学伯克利分校 AMP 实验室 (Algorithms, Machines, and People Lab) 开发，可用来构建大型的、低延迟的数据分析应用程序。

首先，Spark为我们提供了一个全面、统一的框架用于管理各种有着不同性质（文本数据、图表数据等）的数据集和数据源（批量数据或实时的流数据）的大数据处理的需求。

Spark可以将Hadoop集群中的应用在内存中的运行速度提升100倍，甚至能够将应用在磁盘上的运行速度提升10倍。

Spark让开发者可以快速的用Java、Scala或Python编写程序。它本身自带了一个超过80个高阶操作符集合。而且还可以用它在shell中以交互式地查询数据。

除了Map和Reduce操作之外，它还支持SQL查询，流数据，机器学习和图表数据处理。开发者可以在一个数据管道用例中单独使用某一能力或者将这些能力结合在一起使用。

　　分布式存储是一种数据存储技术，通过网络使用企业中的每台机器上的磁盘空间，并将这些分散的存储资源构成一个虚拟的存储设备，数据分散的存储在企业的各个角落。

　　Docker 容器是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的机器上，也可以实现。容器是完全使用机制，相互之间不会有任何接口（类似 iPhone 的 app）。几乎没有性能开销,可以很容易地在机器和数据中心中运行。最重要的是,他们不依赖于任何语言、框架包括系统。

高并发、分布式系统特点：

现在很多高谈阔论，高并发，大流量，分布式，SOA，名词一大堆往往抓不住要点，对于熟悉的人来说，言之无味，而对不熟悉的人来说，更类似大师讲法，除了增加神秘感外，让人越发无从了解。

其实这些问题，本质是成本收益的平衡，严格说，这其实就是所谓技术最关注的问题， 
正因为没有银弹，没有统一的解决方案，所以任何系统都要结合业务自身特点，与软件，硬件平衡一起考虑完整的解决方案。

可以从一个典型的电商平台来分析，

假如，从无到有，有足够人力时间，而且目标也非常明确，一个支持海量商家，海量用户的，海量商品的平台，应该怎么设计？

只要高并发，即便全部是静态页面，哪怕只有一个文件，海量的并发连接也是必须首先解决的。 
这个方案相对比较成熟，可以通过负载均衡，简单增加web服务器，承载浏览器连接。单台服务器nginx能承载的并发连接大致5000到数万， 
根据优化情况，可以简单算出到底需要多少台机器。在用户使用浏览器的情况下，这里几乎没有取巧的地方。 
如果不能接受则只能考虑专用客户端，通过长链接，甚至UDP这类协议，来自己实现。

2.一旦请求全部接入了，就需要考虑处理问题 
如果应用很单一，那么应用服务器就可以简单扩展，类似接入的web服务器，单台时间能处理的请求数，和单位时间总请求数，即可算出需要多少应用服务器，当然一般场景往往与用户相关，这里最重要的就是要解决，应用服务器无状态的问题，这样才能无缝扩展，任何web接入的请求，可以随便找一个空闲的应用服务器丢过去。

典型的，可以把用户相关的信息保存到专门的状态服务器中，请求时仅仅通过cookie提交一个令牌，用令牌从状态服务器获得对应用户的信息。

状态服务器，有一个天生的优势，就是各个用户数据之间往往隔离的，当单台服务器抗不住时，简单增加状态服务器，而在应用服务器上简单根据用户id或令牌，计算出对应的状态服务器即可。

状态服务器可以充分利用各种NoSQL服务，比如典型的，这里系统设计与业务需求就要综合考虑了。

A 如果偶尔丢失状态，可以接受，即可配置成不持久化。此时效率最高。 
万一状态服务器挂了，应用端，简单该向请求到新状态服务器，用户重新登录即可，不会中断太长服务。

B 如果希望尽量少的丢失状态，那么redis就应该定期持久化，并做复制。 
这样某台状态服务器挂了，可以根据情况，选择恢复主服务器，中断一小段时间，数据最完整，或备用状态服务器接管，快速恢复服务，数据可能多丢失一点点。 
大部分用户完全感知不到，个别用户重新登录即可。业务中断也很小。

如果有可能，做成自动切换，会更高效率，但是一定要注意，不是什么都自动的好，如果没有积累，你写的程序，往往无法考虑大量意外，在“正常”的异常情况下可能切换很好，但是更多的异常情况下，有可能更糟糕。

C 如果要求绝对不能丢失状态，允许中断服务一段时间，redis可以配置成每次都持久化。持久化的硬盘也做冗余甚至做成共享存储。 
如果出问题，因为数据都没有丢失，系统重启或更换其他硬件，所有状态即可恢复。但是显然此时redis处理能力将大大减弱。

D 如果要求绝对不能丢失状态，尽量减少中断服务， 
redis可以适当自己改造，将数据成功推送到备份服务器上，且备份服务器持久化之后，再返回成功。那么理论上，当主服务器挂掉，可以立刻切换到备份服务器上，而不丢失数据，用户也基本感知不到变化。当然如何判断主的挂掉，这里还是有大量陷阱，处理不好，反而更多的中断服务。

如果去问一个不太了解技术的产品，这个用户状态到底什么要求，他很可能认为D是理所当然的，因为他完全没有成本意识。 
实际上对于大部分系统，A,B都是更佳的选择，无论对于开发者，运维者，还是最终用户。

A,B简单，因此可靠，不容易出其他问题，开发成本低，运维成本低，最终更稳定，导致最终用户更满意。

只有用户量足够多，技术团队，运维团队足够强，有能力实现更好的D，这时候D才是对产品来说更好的方案。

到2，实际上解决了绝大多数系统的并发问题，因为可以简单的通过增加硬件来扩容。 
但是当应用原来越复杂之后，让一个应用服务器包含所有的服务，是很困难的，从运维成本上考虑，必然有很大浪费，因为每个服务使用频率不一样。 
一些，不太常用的服务，可能全部集中到两台服务器上就足够了，这样从其他大量服务器上将这些服务去掉，相当于整个系统节省大量内存。

而从开发角度，也必然是10个小项目每个10人维护，比100人维护一个大项目更容易，因此从开发角度也要求拆分应用。

拆分应用，虽然有些技术辅助手段，但实际主要还是依赖业务本身的分析，技术仅仅是辅助，比如解决各个应用系统之间数据同步问题，跨系统RPC问题等等。

而流行的SOA，则会努力将服务拆成更小而独立的服务，一方面提高功能复用，另一方面便于开发维护，也方便运维管理。

但是这里有一个误区，认为服务拆分得越小越好，其实，从理论上，服务怎么拆分，传统的面向对象已经指明了方向，低耦合，高内聚， 
说直白些，就是要善于封装，面向对象从来不是类越多，方法越多越好。

所谓SOA治理，关键还是业务梳理！

如果说上面各种问题，目前技术都可以给出比较理想的解决方案，那么持久化瓶颈问题，却始终是最大的问题所在。 
前端接入服务器，应用服务器，都可以很好的横向扩展，而状态服务器，也因为其特殊性（持久化可以不太严格，数据之间无关联），也可以比较好的横向扩展。

而典型的联机交易系统，总是要求数据一致性的，没有产品会说偶尔用户账户上少1分钱，是可以接受的。

传统的银行系统系统，会选择更快的专有共享存储，多机互备，将数据实实在在的写到可靠存储里，存储通过raid方式来保证冗余防止单硬盘故障， 
当主机故障时，无论软硬件，简单将共享存储挂到备机上，来完成切换。

从安全角度，这种方案是非常高的，但是有两个问题，一是价格昂贵，二是系统容量还是有限。

这种方案，其实就是目前大多数云平台提供给中小系统的解决方案，只是用云存储代替了传统昂贵的共享存储。 
如果你的系统可以用云平台的数据库系统或者强劲单机来提供，其实这就是一个合理的好方案。无论你是租用云主机，还是自己弄个物理机。

但是如果系统规模足够大，云平台提供的单机无法满足，或者其云数据库也无法满足（或者仅仅是因为价格太高），那么还是要想办法自己来实现。

首先，存在这样一个库类似传统单机数据库那样，可以无限横向扩展吗？ 
在我看来是不存在的，因为传统单机数据库，重要的就是提供严格的事务支持，多机分布式事务，要想简单横向扩展，至少目前看来是很困难的。

而三者如何权衡，还是要依赖业务！而不是技术。

当然目前因为技术问题P是无法避免的，所以问题往往简化成CA的选择。

对于电商系统，从业务角度，A往往不能舍弃，而C则可以根据业务设计成最终一致性。

比如，购买业务，如果用户账户钱一扣，他的订单就应该是支付成功，单机上这点通过事务很容易实现，但是对于分布式系统，如果做这样的要求，用户未必高兴，因为假设订单系统出了些问题，订单无法更新状态，那么此时只能将用户成功的支付也取消掉！

对于一个庞大的分布式系统，要保证每个系统都正常是不可能的，所以即便放弃A，允许任何一系统故障，整个系统暂停以保证数据一致性，从实际角度看也是不现实的。更不要说，参与系统越多分布协调成本越高，最终可能是即便所有系统都正常，其处理速度也完全无法接受了。

反之，如果支付成功了，允许订单状态暂时没变，就可以等待订单系统恢复后，再将其状态修改为成功。通过业务设计，避免分布式事务，不光得到最大限度的A，也提高了整个系统的处理能力。 具体细节可参看《》

用户会不会容忍这个短暂的数据不一致呢？钱付了，订单状态却没立刻改。

会的，其实现实中他们经常这样，以前去汇款时，自己的钱立刻交了出去，但是对方却没立刻收到，过几天后，对方才收到，或者对方不在了，汇款再退回。

当然另外一些最终一致却不会被接纳，比如，如果存在一段时间，订单先支付成功，用户余额却没扣。

此时用户即可用没扣的余额去购买其他商品，这是系统巨大的漏洞。

所以一定是要和业务结合才能解决现实问题，也因此，在持久层这里，不要期望一个完整的分布式强数据一致性的系统，而应该学习现实世界的实现方式，分析业务，找到可以接受的最终数据一致性方案。

只要能接受最终数据一致性方案，那么就可以将存储系统拆分成多个相对独立的子系统，每个子系统内都是传统的强一致性严格事务实现，而各个系统之间则通过相对松散的消息机制来互动。任何一个子系统都可以故障，操作可以在其他系统被cache，要么随后恢复，要么超时取消。

其实很典型的例子就是第三方支付系统，每个系统都会对接，显然这是两个完全独立的系统,甚至所有者也不同，但是对于支付业务的确很好的实现了，是一个真正意义上的分布式系统。

对于一个电商平台，可以大致描述一下其基础， 
1.一个接入的web集群，用来接入链接 
3.拆分成多个相对独立的应用系统，每个系统都无状态，可横向扩展。 
4.根据应用和数据规模，将数据拆分成多个相对对立的存储系统 
可以是类似：用户系统，订单系统，支付系统这样按功能拆分， 
也可以再拆分成：用户1系统，用户2系统…这些系统功能完全一致，只是保存了不同用户群的数据

其中每个存储系统自己负责容错，不同存储系统通过应用系统通过内部消息来衔接，总是假定其他系统可能故障，也就必须考虑恢复或冲正。

这一切，尤其是3和4显然更多依赖于业务的分析与设计，那么从技术角度，最终的系统就是一个完全分布式的系统，可以支持几乎无限的扩展。

而某些技术，热门中间件，框架，其实仅仅是一个技术手段，并没有想象的那么重要。

　　由中国法学会研究部与腾讯研究院共同发起的“法律人的互联网思维”系列研修会第一期日前在京举行。中国信息通信研究院云计算与大数据研究所所长何宝宏、中国法学会研究部副主任彭伶、腾讯研究院秘书长张钦坤、腾讯研究院金融科技研究中心副主任杜晓宇等围绕“区块链技术及其对法律的影响和挑战”的主题发表了各自的观点。

　　中国信息通信研究院云计算与大数据研究所所长何宝宏说，“自治，分享，分布，开放，偶尔有害，对等，匿名”这些关键词放在一起，就会猜到区块链，但如果时光倒流穿越到20年前，答案应该是互联网。“人总是高估技术的短期影响，而低估技术的长期影响，这是普遍的现象。”

　　对于外界存在大量批评区块链性能低，能耗高，生态链，安全防护，隐私保护，监管缺失，标准缺失，不务正业等声音，何宝宏认为任何新技术的出现都会有很多缺点，但是应该多包容，让子弹飞一会儿。在谈到“价值互联网”时，他认为，以前，数据是信息，关键是传播;现在，数据是资产，关键是保护。区块链的主要价值是保护数据，传播数据是次要的。这也是区块链技术对大数据时代的个人信息保护和数据利用和交易的一种回应。

　　中国法学会研究部副主任彭伶指出，从目前正在进行的一些立法来看，与互联网相关的技术知识正在直接或者间接地影响着立法，并且这种影响正在加剧。这对于法学法律工作者的与互联网相关的技术知识储备提出了更高的要求。但是，目前大多数的法学法律工作者对于互联网技术知识缺乏较为系统深入的了解。因此，我们希望，通过“法律人的互联网思维”研修会，为法律人提供机会充实知识储备，补上法律人欠缺的与互联网相关的技术知识短板。

　　腾讯研究院秘书长张钦坤坦言，法律人只有懂一点技术和商业的变化才能跟得上科技革命的变化。他提出目前移动互联网的流量红利正在消失，前几年不正当竞争领域的风平浪静不再会重现，AI和区块链技术或许会是未来新的机遇或下一个风口。

　　腾讯研究院金融科技研究中心副主任杜晓宇认为，区块链对法律的影响与挑战不宜从单一角度笼统去概括，可以考虑从“区块链技术与法律”、“区块链应用与法律”、“区块链市场与法律”、“区块链骗子与法律”四个维度来展开分析。第一，狭义的区块链技术与法律更加强调在法律框架下制定区块链的技术规则与标准，广义上则包括因为区块链分布式、智能合约等技术与技术伦理、与部分传统民商事基本规则存在不一致、隐私保护与数据流动等方面内容。第二，区块链应用则包括区块链技术在金融、登记公示、证据存储等具体应用上与传统法律关系及相关部门立法冲突与适应的问题。第三区块链市场与法律包括ICO、数字货币交易所、数字货币期货等区块链衍生市场的法律调整。第四，要严格防范借区块链概念行使诈骗的行为，例如虚假宣传、非法集资、非法传销、双向诈骗等，这些行为对真正区块链行业的发展造成严重的损害。(完)