在常见的数据库操作中，大多数业务都是CURD，公司业务，所属岗位都有可能造成这个问题，这些属于OLTP应用。

而对应到现在，天级数据量数据库分析操作，替代大部分数据分析的代码，就是OLAP，直接使用sql语句进行逻辑操作。

在go中使用goroutine，协程中函数是无法对返回数据直接处理error的。官方库中，有着这么一个收纳子任务error的包：errgroup。

errgroup 包为一组子任务的 goroutine 提供了 goroutine 同步，错误取消功能。

对rabbitMq概念的一次小结：

基础操作的代码：RabbitMQ Tutorials。

使用一批训练数据集进行模型训练，需要将训练数据分为：一份训练数据以及一份测试数据。

这样做的目的，也是为了解决模型过拟合，欠拟合的问题。

Go调度器，Goroutine是如何调度的，Go协程运行在用户态还是内核态？

这篇文章大概是要解决这几个问题，整理起来有点麻烦，其实前面的问题，大神们已经讲了很多了，我主要是碰到其中最后一个问题，这算是一道面试题，很有意思的面试问题，估计很少有人会深入考虑这个问题，嗯，其中也包括了我。。。

刚学习Goroutine时，就应该会看到一些文章说过，goroutine是非抢占式的，或者称之为协作式抢占调度，其运行在用户态。

访问策略如图，Apollo整体由三个部件Portal、apollo-configservice和apollo-adminservice(占用端口8070, 8080, 8090)组成：

快速的部署和更新底层设备需要一个类似于分发二进制文件的平台，根据这个需求，依托于etcd做了一个简略的OTA平台。

ETCD又类似于消息发布和订阅的操作，通过key的目录，可以划分不同的空间，执行不同的任务，可以满足我们的需求。

整体设计如下：

context出现在各种组件之中，作为上下文传递数据、控制程序运行。在实际代码coding中，也是经常用到。

1
2

文章作者:lday
原始链接:http://lday.me/2017/02/01/0003_seri-stm-etcd3/

本文翻译自Serializability and Distributed Software Transactional Memory with etcd3

新的etcd3 API引入了新的更加强大的原语，相比较于etcd2的限制，这些新的原语充分利用了系统的能力。作为评估etcd3性能的一部分，我们花费了很大力气来使用新的API开发分布式的并发算法。

etcd3的访问序列化要优于etcd2的隔离模型。当应用更新若干个相关的key时，通常需要这些更新要么全部成功，要么全部失败，进而维持应用程序数据的一致性。在实际应用中，etcd3的事务操作和它的多修订版本数据存储给予了etcd一种用于表达原子性的方式，这种原子性基于对多次修订的序列化。在etcd2上，每一个key的更新是独立提交到数据存储上的；这样就无法做到整个提交的原子性。为了评判etcd3的原语是否正确以及性能情况，我们实现了通用的分布式同步控制“食谱”，并进行了基准测试。

这篇文章关注于etcd3新的最小事务接口所提供的原子性。我们将涵盖etcd3的事务，并且演示通过事务来实现原子更新。接着，我们将通过概要介绍一个简单的客户端侧软事务实现来展示etcd的修订元数据如何自然的映射到软事务内存（STM）上。最后，我们将说明这种软事务内存实现是分布式共享锁的一种高性能替代。