189 8069 5689
简单来说， SetMaxHeap 提供了一种可以设置固定触发阈值的 GC （Garbage Collection垃圾回收）方式
创新互联专注于白水企业网站建设,成都响应式网站建设公司,商城网站开发。白水网站建设公司,为白水等地区提供建站服务。全流程按需求定制设计，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务
官方源码链接
大量临时对象分配导致的 GC 触发频率过高， GC 后实际存活的对象较少，
或者机器内存较充足，希望使用剩余内存，降低 GC 频率的场景
GC 会 STW （ Stop The World ），对于时延敏感场景，在一个周期内连续触发两轮 GC ，那么 STW 和 GC 占用的 CPU 资源都会造成很大的影响， SetMaxHeap 并不一定是完美的，在某些场景下做了些权衡，官方也在进行相关的实验，当前方案仍没有合入主版本。
先看下如果没有 SetMaxHeap ，对于如上所述的场景的解决方案
这里简单说下 GC 的几个值的含义，可通过 GODEBUG=gctrace=1 获得如下数据
这里只关注 128-132-67 MB 135 MB goal ，
分别为 GC开始时内存使用量 - GC标记完成时内存使用量 - GC标记完成时的存活内存量 本轮GC标记完成时的 预期 内存使用量（上一轮 GC 完成时确定）
引用 GC peace设计文档 中的一张图来说明
对应关系如下：
简单说下 GC pacing （信用机制）
GC pacing 有两个目标，
那么当一轮 GC 完成时，如何只根据本轮 GC 存活量去实现这两个小目标呢？
这里实际是根据当前的一些数据或状态去 预估 “未来”，所有会存在些误差
首先确定 gc Goal goal = memstats.heap_marked + memstats.heap_marked*uint64(gcpercent)/100
heap_marked 为本轮 GC 存活量， gcpercent 默认为 100 ，可以通过环境变量 GOGC=100 或者 debug.SetGCPercent(100) 来设置
那么默认情况下 goal = 2 * heap_marked
gc_trigger 是与 goal 相关的一个值（ gc_trigger 大约为 goal 的 90% 左右），每轮 GC 标记完成时，会根据 |Ha-Hg| 和实际使用的 cpu 资源 动态调整 gc_trigger 与 goal 的差值
goal 与 gc_trigger 的差值即为，为 GC 期间分配的对象所预留的空间
GC pacing 还会预估下一轮 GC 发生时，需要扫描对象对象的总量，进而换算为下一轮 GC 所需的工作量，进而计算出 mark assist 的值
本轮 GC 触发（ gc_trigger ），到本轮的 goal 期间，需要尽力完成 GC mark 标记操作，所以当 GC 期间，某个 goroutine 分配大量内存时，就会被拉去做 mark assist 工作，先进行 GC mark 标记赚取足够的信用值后，才能分配对应大小的对象
根据本轮 GC 存活的内存量（ heap_marked ）和下一轮 GC 触发的阈值（ gc_trigger ）计算 sweep assist 的值，本轮 GC 完成，到下一轮 GC 触发（ gc_trigger ）时，需要尽力完成 sweep 清扫操作
预估下一轮 GC 所需的工作量的方式如下：
继续分析文章开头的问题，如何充分利用剩余内存，降低 GC 频率和 GC 对 CPU 的资源消耗
如上图可以看出， GC 后，存活的对象为 2GB 左右，如果将 gcpercent 设置为 400 ，那么就可以将下一轮 GC 触发阈值提升到 10GB 左右
前面一轮看起来很好，提升了 GC 触发的阈值到 10GB ，但是如果某一轮 GC 后的存活对象到达 2.5GB 的时候，那么下一轮 GC 触发的阈值，将会超过内存阈值，造成 OOM （ Out of Memory ），进而导致程序崩溃。
可以通过 GOGC=off 或者 debug.SetGCPercent(-1) 来关闭 GC
可以通过进程外监控内存使用状态，使用信号触发的方式通知程序，或 ReadMemStats 、或 linkname runtime.heapRetained 等方式进行堆内存使用的监测
可以通过调用 runtime.GC() 或者 debug.FreeOSMemory() 来手动进行 GC 。
这里还需要说几个事情来解释这个方案所存在的问题
通过 GOGC=off 或者 debug.SetGCPercent(-1) 是如何关闭 GC 的？
gc 4 @1.006s 0%: 0.033+5.6+0.024 ms clock, 0.27+4.4/11/25+0.19 ms cpu, 428-428-16 MB, 17592186044415 MB goal, 8 P (forced)
通过 GC trace 可以看出，上面所说的 goal 变成了一个很诡异的值 17592186044415
实际上关闭 GC 后， Go 会将 goal 设置为一个极大值 ^uint64(0) ，那么对应的 GC 触发阈值也被调成了一个极大值，这种处理方式看起来也没什么问题，将阈值调大，预期永远不会再触发 GC
那么如果在关闭 GC 的情况下，手动调用 runtime.GC() 会导致什么呢？
由于 goal 和 gc_trigger 被设置成了极大值， mark assist 和 sweep assist 也会按照这个错误的值去计算，导致工作量预估错误，这一点可以从 trace 中进行证明
可以看到很诡异的 trace 图，这里不做深究，该方案与 GC pacing 信用机制不兼容
记住，不要在关闭 GC 的情况下手动触发 GC ，至少在当前 Go1.14 版本中仍存在这个问题
SetMaxHeap 的实现原理，简单来说是强行控制了 goal 的值
注： SetMaxHeap ，本质上是一个软限制，并不能解决 极端场景 下的 OOM ，可以配合内存监控和 debug.FreeOSMemory() 使用
SetMaxHeap 控制的是堆内存大小， Go 中除了堆内存还分配了如下内存，所以实际使用过程中，与实际硬件内存阈值之间需要留有一部分余量。
对于文章开始所述问题，使用 SetMaxHeap 后，预期的 GC 过程大概是这个样子
简单用法1
该方法简单粗暴，直接将 goal 设置为了固定值
注：通过上文所讲，触发 GC 实际上是 gc_trigger ，所以当阈值设置为 12GB 时，会提前一点触发 GC ，这里为了描述方便，近似认为 gc_trigger=goal
简单用法2
当不关闭 GC 时， SetMaxHeap 的逻辑是， goal 仍按照 gcpercent 进行计算，当 goal 小于 SetMaxHeap 阈值时不进行处理；当 goal 大于 SetMaxHeap 阈值时，将 goal 限制为 SetMaxHeap 阈值
注：通过上文所讲，触发 GC 实际上是 gc_trigger ，所以当阈值设置为 12GB 时，会提前一点触发 GC ，这里为了描述方便，近似认为 gc_trigger=goal
切换到 go1.14 分支，作者选择了 git checkout go1.14.5
选择官方提供的 cherry-pick 方式(可能需要梯子，文件改动不多，我后面会列出具体改动)
git fetch "" refs/changes/67/227767/3 git cherry-pick FETCH_HEAD
需要重新编译Go源码
注意点：
下面源码中的官方注释说的比较清楚，在一些关键位置加入了中文注释
入参bytes为要设置的阈值
notify 简单理解为 GC 的策略 发生变化时会向 channel 发送通知，后续源码可以看出“策略”具体指哪些内容
返回值为本次设置之前的 MaxHeap 值
$GOROOT/src/runtime/debug/garbage.go
$GOROOT/src/runtime/mgc.go
注：作者尽量用通俗易懂的语言去解释 Go 的一些机制和 SetMaxHeap 功能，可能有些描述与实现细节不完全一致，如有错误还请指出
在Malwarebytes 我们经历了显著的增长，自从我一年前加入了硅谷的公司，一个主要的职责成了设计架构和开发一些系统来支持一个快速增长的信息安全公司和所有需要的设施来支持一个每天百万用户使用的产品。我在反病毒和反恶意软件行业的不同公司工作了12年，从而我知道由于我们每天处理大量的数据，这些系统是多么复杂。
有趣的是，在过去的大约9年间，我参与的所有的web后端的开发通常是通过Ruby on Rails技术实现的。不要错怪我。我喜欢Ruby on Rails，并且我相信它是个令人惊讶的环境。但是一段时间后，你会开始以ruby的方式开始思考和设计系统，你会忘记，如果你可以利用多线程、并行、快速执行和小内存开销，软件架构本来应该是多么高效和简单。很多年期间，我是一个c/c++、Delphi和c#开发者，我刚开始意识到使用正确的工具可以把复杂的事情变得简单些。
作为首席架构师，我不会很关心在互联网上的语言和框架战争。我相信效率、生产力。代码可维护性主要依赖于你如何把解决方案设计得很简单。
问题
当工作在我们的匿名遥测和分析系统中，我们的目标是可以处理来自于百万级别的终端的大量的POST请求。web处理服务可以接收包含了很多payload的集合的JSON数据，这些数据需要写入Amazon S3中。接下来，map-reduce系统可以操作这些数据。
按照习惯，我们会调研服务层级架构，涉及的软件如下：
Sidekiq
Resque
DelayedJob
Elasticbeanstalk Worker Tier
RabbitMQ
and so on…
搭建了2个不同的集群，一个提供web前端，另外一个提供后端处理，这样我们可以横向扩展后端服务的数量。
但是，从刚开始，在 讨论阶段我们的团队就知道我们应该使用Go，因为我们看到这会潜在性地成为一个非常庞大（ large traffic）的系统。我已经使用了Go语言大约2年时间，我们开发了几个系统，但是很少会达到这样的负载（amount of load）。
我们开始创建一些结构，定义从POST调用得到的web请求负载，还有一个上传到S3 budket的函数。
type PayloadCollection struct {
WindowsVersion string `json:"version"`
Token string `json:"token"`
Payloads []Payload `json:"data"`
}
type Payload struct {
// [redacted]
}
func (p *Payload) UploadToS3() error {
// the storageFolder method ensures that there are no name collision in
// case we get same timestamp in the key name
storage_path := fmt.Sprintf("%v/%v", p.storageFolder, time.Now().UnixNano())
bucket := S3Bucket
b := new(bytes.Buffer)
encodeErr := json.NewEncoder(b).Encode(payload)
if encodeErr != nil {
return encodeErr
}
// Everything we post to the S3 bucket should be marked 'private'
var acl = s3.Private
var contentType = "application/octet-stream"
return bucket.PutReader(storage_path, b, int64(b.Len()), contentType, acl, s3.Options{})
}
本地Go routines方法
刚开始，我们采用了一个非常本地化的POST处理实现，仅仅尝试把发到简单go routine的job并行化：
func payloadHandler(w http.ResponseWriter, r *http.Request) {
if r.Method != "POST" {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
// Read the body into a string for json decoding
var content = PayloadCollection{}
err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)
if err != nil {
w.Header().Set("Content-Type", "application/json; charset=UTF-8")
w.WriteHeader(http.StatusBadRequest)
return
}
// Go through each payload and queue items individually to be posted to S3
for _, payload := range content.Payloads {
go payload.UploadToS3() // ----- DON'T DO THIS
}
w.WriteHeader(http.StatusOK)
}
对于中小负载，这会对大多数的人适用，但是大规模下，这个方案会很快被证明不是很好用。我们期望的请求数，不在我们刚开始计划的数量级，当我们把第一个版本部署到生产环境上。我们完全低估了流量。
上面的方案在很多地方很不好。没有办法控制我们产生的go routine的数量。由于我们收到了每分钟1百万的POST请求，这段代码很快就崩溃了。
再次尝试
我们需要找一个不同的方式。自开始我们就讨论过， 我们需要保持请求处理程序的生命周期很短，并且进程在后台产生。当然，这是你在Ruby on Rails的世界里必须要做的事情，否则你会阻塞在所有可用的工作 web处理器上，不管你是使用puma、unicore还是passenger（我们不要讨论JRuby这个话题）。然后我们需要利用常用的处理方案来做这些，比如Resque、 Sidekiq、 SQS等。这个列表会继续保留，因为有很多的方案可以实现这些。
所以，第二次迭代，我们创建了一个缓冲channel，我们可以把job排队，然后把它们上传到S3。因为我们可以控制我们队列中的item最大值，我们有大量的内存来排列job，我们认为只要把job在channel里面缓冲就可以了。
var Queue chan Payload
func init() {
Queue = make(chan Payload, MAX_QUEUE)
}
func payloadHandler(w http.ResponseWriter, r *http.Request) {
...
// Go through each payload and queue items individually to be posted to S3
for _, payload := range content.Payloads {
Queue - payload
}
...
}
接下来，我们再从队列中取job，然后处理它们。我们使用类似于下面的代码：
func StartProcessor() {
for {
select {
case job := -Queue:
job.payload.UploadToS3() // -- STILL NOT GOOD
}
}
}
说实话，我不知道我们在想什么。这肯定是一个满是Red-Bulls的夜晚。这个方法不会带来什么改善，我们用了一个 有缺陷的缓冲队列并发，仅仅是把问题推迟了。我们的同步处理器同时仅仅会上传一个数据到S3，因为来到的请求远远大于单核处理器上传到S3的能力，我们的带缓冲channel很快达到了它的极限，然后阻塞了请求处理逻辑的queue更多item的能力。
我们仅仅避免了问题，同时开始了我们的系统挂掉的倒计时。当部署了这个有缺陷的版本后，我们的延时保持在每分钟以常量增长。
最好的解决方案
我们讨论过在使用用Go channel时利用一种常用的模式，来创建一个二级channel系统，一个来queue job，另外一个来控制使用多少个worker来并发操作JobQueue。
想法是，以一个恒定速率并行上传到S3，既不会导致机器崩溃也不好产生S3的连接错误。这样我们选择了创建一个Job/Worker模式。对于那些熟悉Java、C#等语言的开发者，可以把这种模式想象成利用channel以golang的方式来实现了一个worker线程池，作为一种替代。
var (
MaxWorker = os.Getenv("MAX_WORKERS")
MaxQueue = os.Getenv("MAX_QUEUE")
)
// Job represents the job to be run
type Job struct {
Payload Payload
}
// A buffered channel that we can send work requests on.
var JobQueue chan Job
// Worker represents the worker that executes the job
type Worker struct {
WorkerPool chan chan Job
JobChannel chan Job
quit chan bool
}
func NewWorker(workerPool chan chan Job) Worker {
return Worker{
WorkerPool: workerPool,
JobChannel: make(chan Job),
quit: make(chan bool)}
}
// Start method starts the run loop for the worker, listening for a quit channel in
// case we need to stop it
func (w Worker) Start() {
go func() {
for {
// register the current worker into the worker queue.
w.WorkerPool - w.JobChannel
select {
case job := -w.JobChannel:
// we have received a work request.
if err := job.Payload.UploadToS3(); err != nil {
log.Errorf("Error uploading to S3: %s", err.Error())
}
case -w.quit:
// we have received a signal to stop
return
}
}
}()
}
// Stop signals the worker to stop listening for work requests.
func (w Worker) Stop() {
go func() {
w.quit - true
}()
}
我们已经修改了我们的web请求handler，用payload创建一个Job实例，然后发到JobQueue channel，以便于worker来获取。
func payloadHandler(w http.ResponseWriter, r *http.Request) {
if r.Method != "POST" {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
// Read the body into a string for json decoding
var content = PayloadCollection{}
err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)
if err != nil {
w.Header().Set("Content-Type", "application/json; charset=UTF-8")
w.WriteHeader(http.StatusBadRequest)
return
}
// Go through each payload and queue items individually to be posted to S3
for _, payload := range content.Payloads {
// let's create a job with the payload
work := Job{Payload: payload}
// Push the work onto the queue.
JobQueue - work
}
w.WriteHeader(http.StatusOK)
}
在web server初始化时，我们创建一个Dispatcher，然后调用Run()函数创建一个worker池子，然后开始监听JobQueue中的job。
dispatcher := NewDispatcher(MaxWorker)
dispatcher.Run()
下面是dispatcher的实现代码：
type Dispatcher struct {
// A pool of workers channels that are registered with the dispatcher
WorkerPool chan chan Job
}
func NewDispatcher(maxWorkers int) *Dispatcher {
pool := make(chan chan Job, maxWorkers)
return Dispatcher{WorkerPool: pool}
}
func (d *Dispatcher) Run() {
// starting n number of workers
for i := 0; i d.maxWorkers; i++ {
worker := NewWorker(d.pool)
worker.Start()
}
go d.dispatch()
}
func (d *Dispatcher) dispatch() {
for {
select {
case job := -JobQueue:
// a job request has been received
go func(job Job) {
// try to obtain a worker job channel that is available.
// this will block until a worker is idle
jobChannel := -d.WorkerPool
// dispatch the job to the worker job channel
jobChannel - job
}(job)
}
}
}
注意到，我们提供了初始化并加入到池子的worker的最大数量。因为这个工程我们利用了Amazon Elasticbeanstalk带有的docker化的Go环境，所以我们常常会遵守12-factor方法论来配置我们的生成环境中的系统，我们从环境变了读取这些值。这种方式，我们控制worker的数量和JobQueue的大小，所以我们可以很快的改变这些值，而不需要重新部署集群。
var (
MaxWorker = os.Getenv("MAX_WORKERS")
MaxQueue = os.Getenv("MAX_QUEUE")
)
直接结果
我们部署了之后，立马看到了延时降到微乎其微的数值，并未我们处理请求的能力提升很大。
Elastic Load Balancers完全启动后，我们看到ElasticBeanstalk 应用服务于每分钟1百万请求。通常情况下在上午时间有几个小时，流量峰值超过每分钟一百万次。
我们一旦部署了新的代码，服务器的数量从100台大幅 下降到大约20台。
我们合理配置了我们的集群和自动均衡配置之后，我们可以把服务器的数量降至4x EC2 c4.Large实例，并且Elastic Auto-Scaling设置为如果CPU达到5分钟的90%利用率，我们就会产生新的实例。
总结
在我的书中，简单总是获胜。我们可以使用多队列、后台worker、复杂的部署设计一个复杂的系统，但是我们决定利用Elasticbeanstalk 的auto-scaling的能力和Go语言开箱即用的特性简化并发。
我们仅仅用了4台机器，这并不是什么新鲜事了。可能它们还不如我的MacBook能力强大，但是却处理了每分钟1百万的写入到S3的请求。
处理问题有正确的工具。当你的 Ruby on Rails 系统需要更强大的web handler时，可以考虑下ruby生态系统之外的技术，或许可以得到更简单但更强大的替代方案。
区块链技术概念
区块链技术概念，现如今，区块链已经成为大部分人关注的领域，很多企业也早已深入其中研究该技术情况，但是还有人对于它不是很了解，下面我分享一篇关于区块链技术概念的相关信息。
区块链技术概念1
区块链的基本概念和工作原理
1、基本概念
区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。所谓共识机制是区块链系统中实现不同节点之间建立信任、获取权益的数学算法。
区块链Blockchain、是比特币的一个重要概念，它本质上是一个去中心化的数据库，同时作为比特币的底层技术。区块链是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一次比特币网络交易的信息，用于验证其信息的有效性防伪、和生成下一个区块。
狭义来讲，区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构， 并以密码学方式保证的不可篡改和不可伪造的分布式账本。
广义来讲，区块链技术是利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算方式。
2、工作原理
区块链系统由数据层、网络层、共识层、激励层、合约层和应用层组成。 其中，数据层封装了底层数据区块以及相关的数据加密和时间戳等基础数据和基本算法；网络层则包括分布式组网机制、数据传播机制和数据验证机制等；共识层主要封装网络节点的各类共识算法；激励层将经济因素集成到区块链技术体系中来，主要包括经济激励的发行机制和分配机制等；合约层主要封装各类脚本、算法和智能合约，是区块链可编程特性的基础；应用层则封装了区块链的各种应用场景和案例。该模型中，基于时间戳的链式区块结构、分布式节点的共识机制、基于共识算力的经济激励和灵活可编程的智能合约是区块链技术最具代表性的创新点。
区块链主要解决的交易的信任和安全问题，因此它针对这个问题提出了四个技术创新：
1、分布式账本，就是交易记账由分布在不同地方的多个节点共同完成，而且每一个节点都记录的是完整的账目，因此它们都可以参与监督交易合法性，同时也可以共同为其作证。
跟传统的分布式存储有所不同，区块链的分布式存储的独特性主要体现在两个方面：一是区块链每个节点都按照块链式结构存储完整的数据，传统分布式存储一般是将数据按照一定的规则分成多份进行存储。二是区块链每个节点存储都是独立的、地位等同的，依靠共识机制保证存储的一致性，而传统分布式存储一般是通过中心节点往其他备份节点同步数据。 [8]
没有任何一个节点可以单独记录账本数据，从而避免了单一记账人被控制或者被贿赂而记假账的可能性。也由于记账节点足够多，理论上讲除非所有的节点被破坏，否则账目就不会丢失，从而保证了账目数据的安全性。
2、非对称加密和授权技术，存储在区块链上的交易信息是公开的，但是账户身份信息是高度加密的，只有在数据拥有者授权的情况下才能访问到，从而保证了数据的安全和个人的隐私。
3、共识机制，就是所有记账节点之间怎么达成共识，去认定一个记录的有效性，这既是认定的手段，也是防止篡改的手段。区块链提出了四种不同的共识机制，适用于不同的应用场景，在效率和安全性之间取得平衡。
区块链的共识机制具备“少数服从多数”以及“人人平等”的特点，其中“少数服从多数”并不完全指节点个数，也可以是计算能力、股权数或者其他的计算机可以比较的特征量。“人人平等”是当节点满足条件时，所有节点都有权优先提出共识结果、直接被其他节点认同后并最后有可能成为最终共识结果。以比特币为例，采用的是工作量证明，只有在控制了全网超过51%的记账节点的情况下，才有可能伪造出一条不存在的记录。当加入区块链的节点足够多的时候，这基本上不可能，从而杜绝了造假的可能.
4、智能合约，智能合约是基于这些可信的不可篡改的数据，可以自动化的执行一些预先定义好的规则和条款。以保险为例，如果说每个人的信息包括医疗信息和风险发生的信息、都是真实可信的，那就很容易的在一些标准化的保险产品中，去进行自动化的理赔.
3、其它
互联网交换的是信息，区块链交换的是价值。人类历史和互联网历史可以用八个字理解：分久必合合久必分，到了分久必合的时代，网络信息全部散在互联网上面，大家要挖掘信息非常不容易，这时会出现像谷歌和脸 书等的平台，它做的唯一的事情就是把我们所有的信息重新组合了一下。互联网时代垄断巨头们重组的就是信息，并不是产生自己的信息，产生的信息完全是我们个人。一旦信息重组，就会出现一个新的垄断巨人，所以就到了分久必合的时代。现在由于区块链技术产生又到了合久必分时代，又是新的多中心化，新的多中心化之后赋能产生新的价值，这些数据会在我们自己的手上，个人数据产生价值是归自己所有，这是这个时代最最激动人心的时代。
区块链的价值有哪些？低成本建立信任的机制，确立数权，解决数据的.产权。
目前区块链技术不断发展，包括现在的单链向多链发展，而且技术能够在进一步扩展，我想未来还是可能会出现，特别是在交易等方面出现颠覆性的，特别是对现有产业的很多颠覆性的场景。
区块链的本质是在不可信的网络建立可信的信息交换。
一带一路+一链。区块链更大的不是制造信任，而是让信任产生无损的传递，整个降低社会的摩擦成本，从而提高整个效益。
现在区块链本身还是初始阶段，所以包括区块链的信息传递、加密，这个过程中出现量子加密和其他加密，实际上对区块链本身所采用的加密算法攻击现象也时有发生。包括区块链也是作为一种资产的认定，数字资产的一个认定，但是现在我们很多都是用密码算法，或者是作为我们来解密的钥匙，但是如果密码忘记了，很可能你现在的资产就丢掉了，你不能够在得到你原来的这些资产，所以在资产管理，包括信息传递和一些安全这些方面，应该说都还是存在着一些隐患。当然那么从技术角度，现在我们区块链本身处理的速度，或者说本身的扩展性，因为从工作机理的角度来看，是要把整个账本要复制给所有的参与人员，所以在区块链本身的运作效率和扩展性方面还是比较受限的。这些我们觉得都还是需要进一步在技术方面有进一步的发展。
区块链平台这些底层技术，又形成包括区块链钱包、区块链浏览器、节点竞选、矿机、矿池、开发组件、开发模块、技术社区及项目社群等一系列的生态系统，这些生态系统的完善程度直接决定着区块链底层平台的使用效率和效果。
4、蒙代尔的不可能三角
去中心化、高效、安全，不可能实现三者全部同时达到极致。
区块链技术概念2
区块链的本质是一种分布式记账技术，与之相对的是中心式记账技术，中心式记账技术在我们目前的生活中广泛存在。区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。
区块链Blockchain、，是比特币的一个重要概念，它本质上是一个去中心化的数据库，同时作为比特币的底层技术，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次比特币网络交易的信息，用于验证e69da5e887aa7a6431333431343061其信息的有效性防伪、和生成下一个区块。
狭义来讲，区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构， 并以密码学方式保证的不可篡改和不可伪造的分布式账本。
广义来讲，区块链技术是利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算方式。
区块链技术通俗的理解就是：把“物”的前、后、左、右区块用一种技术连接成一个链条，但每个区块的原始数据不可篡改，是一种物联网范畴的、可以让参与者信任的“各个模块链动”的技术。区块链技术的应用，离不开互联道网，也离不开物联网，是建立在二者融合互动基础上的、但又让参与者各自保持独回立的去中心化、、并共同拥有这套价值链共建共享、的技术。
区块链的特征：去中心化、开放性、自治性、信息不可篡改，匿名性。
区块链是一个能够传递价值的网络，对可以传递价值的网络的需求是推动区块链技术产生的重要原因。在对于保护带有所有权或者其他价值的信息需求的推动下，区块链出现了。区块链通过公私钥密码学、分布式存储等技术手段，一方面保证了带有价值的信息的高效传递，另一方面保证了这些信息在传递的过程中不会被轻易的复制篡改。
从区块链诞生的必然性来理解区块链的内涵，区块链是解决了中心化记账缺点、解决了分布式一致性问题的分布式记账技术，同时也是连接互联网升级为保证带有价值的信息安全高效传递的价值网络。
区块链技术概念3
区块链： 区块链就像是一个全球唯一的帐簿，或者说是数据库，记录了网络中所有交易历史。
以太坊虚拟机(EVM)： 它让你能在以太坊上写出更强大的程序比特币上也可以写脚本程序、。它有时也用来指以太坊区块链，负责执行智能合约以及一切。
节点：你可以运行节点，通过它读写以太坊区块链，也即使用以太坊虚拟机。完全节点需要下载整个区块链。轻节点仍在开发中。
矿工：挖矿，也就是处理区块链上的区块的节点。这个网页可以看到当前活跃的一部分以太坊矿工：stats.ethdev点抗 。
工作量证明：矿工们总是在竞争解决一些数学问题。第一个解出答案的(算出下一个区块)将获得以太币作为奖励。然后所有节点都更新自己的区块链。所有想要算出下一个区块的矿工都有与其他节点保持同步，并且维护同一个区块链的动力，因此整个网络总是能达成共识。(注意：以太坊正计划转向没有矿工的权益证明系统(POS)，不过那不在本文讨论范围之内。)
以太币：缩写ETH。一种你可以购买和使用的真正的数字货币。这里是可以交易以太币的其中一家交易所的走势图。在写这篇文章的时候，1个以太币价值65美分。
Gas：在以太坊上执行程序以及保存数据都要消耗一定量的以太币，Gas是以太币转换而成。这个机制用来保证效率。
DApp: 以太坊社区把基于智能合约的应用称为去中心化的应用程序(Decentralized App)。DApp的目标是(或者应该是)让你的智能合约有一个友好的界面，外加一些额外的东西，例如IPFS可以存储和读取数据的去中心化网络，不是出自以太坊团队但有类似的精神)。DApp可以跑在一台能与以太坊节点交互的中心化服务器上，也可以跑在任意一个以太坊平等节点上。(花一分钟思考一下：与一般的网站不同，DApp不能跑在普通的服务器上。他们需要提交交易到区块链并且从区块链而不是中心化数据库读取重要数据。相对于典型的用户登录系统，用户有可能被表示成一个钱包地址而其它用户数据保存在本地。许多事情都会与目前的web应用有不同架构。)
以太坊客户端，智能合约语言
编写和部署智能合约并不要求你运行一个以太坊节点。下面有列出基于浏览器的IDE和API。但如果是为了学习的话，还是应该运行一个以太坊节点，以便理解其中的基本组件，何况运行节点也不难。
运行以太坊节点可用的客户端
以太坊有许多不同语言的客户端实现即多种与以太坊网络交互的方法、，包括C++, Go, Python, Java, Haskell等等。为什么需要这么多实现？不同的实现能满足不同的需求例如Haskell实现的目标是可以被数学验证、，能使以太坊更加安全，能丰富整个生态系统。
在写作本文时，我使用的是Go语言实现的客户端geth (go-ethereum)，其他时候还会使用一个叫testrpc的工具, 它使用了Python客户端pyethereum。后面的例子会用到这些工具。
关于挖矿：挖矿很有趣，有点像精心照料你的室内盆栽，同时又是一种了解整个系统的方法。虽然以太币现在的价格可能连电费都补不齐，但以后谁知道呢。人们正在创造许多酷酷的DApp, 可能会让以太坊越来越流行。
交互式控制台:客户端运行起来后，你就可以同步区块链，建立钱包，收发以太币了。使用geth的一种方式是通过Javascript控制台。此外还可以使用类似cURL的命令通过JSON RPC来与客户端交互。本文的目标是带大家过一边DApp开发的流程，因此这块就不多说了。但是我们应该记住这些命令行工具是调试，配置节点，以及使用钱包的利器。
在测试网络运行节点: 如果你在正式网络运行geth客户端，下载整个区块链与网络同步会需要相当时间。你可以通过比较节点日志中打印的最后一个块号和stats.ethdev点抗 上列出的最新块来确定是否已经同步。) 另一个问题是在正式网络上跑智能合约需要实实在在的以太币。在测试网络上运行节点的话就没有这个问题。此时也不需要同步整个区块链，创建一个自己的私有链就勾了，对于开发来说更省时间。
Testrpc:用geth可以创建一个测试网络，另一种更快的创建测试网络的方法是使用testrpc. Testrpc可以在启动时帮你创建一堆存有资金的测试账户。它的运行速度也更快因此更适合开发和测试。你可以从testrpc起步，然后随着合约慢慢成型，转移到geth创建的测试网络上 - 启动方法很简单，只需要指定一个networkid：geth --networkid "12345"。这里是testrpc的代码仓库，下文我们还会再讲到它。
接下来我们来谈谈可用的编程语言，之后就可以开始真正的编程了。写智能合约用的编程语言用Solidity就好。
要写智能合约有好几种语言可选：有点类似Javascript的Solidity, 文件扩展名是.sol. 和Python接近的Serpent, 文件名以.se结尾。还有类似Lisp的LLL。Serpent曾经流行过一段时间，但现在最流行而且最稳定的要算是Solidity了，因此用Solidity就好。听说你喜欢Python? 用Solidity。
solc编译器: 用Solidity写好智能合约之后，需要用solc来编译。它是一个来自C++客户端实现的组件又一次，不同的实现产生互补、，这里是安装方法。如果你不想安装solc也可以直接使用基于浏览器的编译器，例如Solidity real-time compiler或者Cosmo。后文有关编程的部分会假设你安装了solc。
web3.js API. 当Solidity合约编译好并且发送到网络上之后，你可以使用以太坊的web3.js JavaScript API来调用它，构建能与之交互的web应用。
区块链需要学的课程有：1.Khan Academy；2.Udemy；3. Lynda；4.Coursera；5.PluralSight等。另外，学习区块链你还得知道区块链与编程语言的关系。学习区块链开发建议建立在Go语言和java基础上，而且Go语言的学习难度比Java略低。
Khan Academy
如果你想重温一下你的比特币知识，或者从头开始学习加密货币，知识点讲解的很彻底，并且会让你在区块链的道路上走向正确的方向。您可以通过8个独立的步骤，从基本的概述到对加密哈希函数、数字签名、工作量证明和区块链安全性的解释。
2.Udemy
你不会因为参加2小时的在线课程而得到哈佛大学的教育。但实际上， 作为一个区块链爱好者， Udemy 可能更有用。根据你的技术水平， 这里的每个人都有很多东西。
对于那些想了解区块链基本知识的人来说， 有一个很好的课程叫做“ 区块链和比特币的基础”。在上面的课程中，你可以得到2小时的课程，可下载的资源，以及在你想要完成课程后，你可以随时访问课程的机会。
如果这能激励你继续上课，你也会得到证书。但最重要的是，你会对比特币的基本概念有一个深刻的了解。
3. Lynda
LinkedIn的Lynda提供了跨越所有级别的大量不同课程。
4.Coursera
Coursera的价格随着复杂性的不同而不同，尽管它们确实有一些免费的选择，鼓励你购买单独的补充课程材料。
课程由斯坦福、麻省理工学院和普林斯顿等大学的教授创建和教授，如果你想寻找优秀的导师，课程设置是个明智的选择。通过这些课程，你不会得到普林斯顿的证书，但是你会接触到一些学术界最聪明的人。
其中一个特别突出的课程是“比特币和加密技术”，该课程由普林斯顿大学的四位主要教授进行教授。这是一个为期11周的计划，涵盖密码学、比特币挖掘、规则、挖掘谜题，甚至还有一个关于altcoins的章节。此外，本课程还包括详细的讲课、练习、继续阅读和家庭作业。
5.PluralSight
PluralSight充满了新的技术课程，这些课程都是实际操作和具体的。例如，如果你想学习MySQL或Javascript等编程语言。