不同语言session能否共享?比如PHP和go,谁做过类似的东西

tupunco 回复了问题 • 7 人关注 • 7 个回复 • 997 次浏览 • 1 天前 • 来自相关话题

变量可以和import的包重名了?

回复

localvar 发起了问题 • 1 人关注 • 0 个回复 • 136 次浏览 • 4 天前 • 来自相关话题

golang有没有好的开源游戏框架

cye 回复了问题 • 21 人关注 • 12 个回复 • 5427 次浏览 • 2017-08-16 17:23 • 来自相关话题

go的beego框架在不使用orm的情况下怎么操作数据库?

jsharkc 回复了问题 • 4 人关注 • 3 个回复 • 179 次浏览 • 2017-08-14 10:53 • 来自相关话题

golang sync mutex

kodango 回复了问题 • 4 人关注 • 4 个回复 • 257 次浏览 • 2017-08-09 11:21 • 来自相关话题

警告:一个包含nil指针的接口不是nil接口

simple 回复了问题 • 7 人关注 • 5 个回复 • 362 次浏览 • 2017-08-06 15:32 • 来自相关话题

GOLANG中time.After释放的问题

winlin 发表了文章 • 7 个评论 • 934 次浏览 • 2017-07-29 11:58 • 来自相关话题

在谢大群里看到有同学在讨论time.After泄漏的问题,就算时间到了也不会释放,瞬间就惊呆了,忍不住做了试验,结果发现应该没有这么的恐怖的,是有泄漏的风险不过不算是泄漏,先看API的说明:

查看全部
					

在谢大群里看到有同学在讨论time.After泄漏的问题,就算时间到了也不会释放,瞬间就惊呆了,忍不住做了试验,结果发现应该没有这么的恐怖的,是有泄漏的风险不过不算是泄漏,先看API的说明:


// After waits for the duration to elapse and then sends the current time
// on the returned channel.
// It is equivalent to NewTimer(d).C.
// The underlying Timer is not recovered by the garbage collector
// until the timer fires. If efficiency is a concern, use NewTimer
// instead and call Timer.Stop if the timer is no longer needed.
func After(d Duration) <-chan Time {
return NewTimer(d).C
}

提到了一句The underlying Timer is not recovered by the garbage collector,这句挺吓人不会被GC回收,不过后面还有条件until the timer fires,说明fire后是会被回收的,所谓fire就是到时间了,写个例子证明下压压惊:


package main

import "time"

func main() {
for {
<- time.After(10 * time.Nanosecond)
}
}

显示内存稳定在5.3MB,CPU为161%,肯定被GC回收了的。当然如果放在goroutine也是没有问题的,一样会回收:


package main

import "time"

func main() {
for i := 0; i < 100; i++ {
go func(){
for {
<- time.After(10 * time.Nanosecond)
}
}()
}
time.Sleep(1 * time.Hour)
}

只是资源消耗会多一点,CPU为422%,内存占用6.4MB。因此:



Remark: time.After(d)在d时间之后就会fire,然后被GC回收,不会造成资源泄漏的。



那么API所说的If efficieny is a concern, user NewTimer instead and call Timer.Stop是什么意思呢?这是因为一般time.After会在select中使用,如果另外的分支跑得更快,那么timer是不会立马释放的(到期后才会释放),比如这种:


select {
case time.After(3*time.Second):
return errTimeout
case packet := packetChannel:
// process packet.
}

如果packet非常多,那么总是会走到下面的分支,上面的timer不会立刻释放而是在3秒后才能释放,和下面代码一样:


package main

import "time"

func main() {
for {
select {
case <-time.After(3 * time.Second):
default:
}
}
}

这个时候,就相当于会堆积了3秒的timer没有释放而已,会不断的新建和释放timer,内存会稳定在2.8GB,这个当然就不是最好的了,可以主动释放:


package main

import "time"

func main() {
for {
t := time.NewTimer(3*time.Second)

select {
case <- t.C:
default:
t.Stop()
}
}
}

这样就不会占用2.8GB内存了,只有5MB左右。因此,总结下这个After的说明:



  1. GC肯定会回收time.After的,就在d之后就回收。一般情况下让系统自己回收就好了。

  2. 如果有效率问题,应该使用Timer在不需要时主动Stop。大部分时候都不用考虑这个问题的。


交作业。

关于The go programming language 课后练习的两个问题

fiisio 回复了问题 • 2 人关注 • 1 个回复 • 171 次浏览 • 2017-07-28 09:37 • 来自相关话题

关于 二维码 解析

stirlingx 回复了问题 • 9 人关注 • 13 个回复 • 1121 次浏览 • 2017-07-22 09:33 • 来自相关话题

如何从题库中提取出题干,选项,答案各类要素?

xiaoma 回复了问题 • 4 人关注 • 3 个回复 • 300 次浏览 • 2017-07-17 10:43 • 来自相关话题

Serverless架构用这5大优势,挽救了后来7亿用户的Instagram

数人云 发表了文章 • 0 个评论 • 299 次浏览 • 2017-07-06 14:26 • 来自相关话题

Markdown


数人云之前分享的文章:《关于Serverless架构及平台选择,你知道多少?》详细地讲述了发展历史和公有云的Serverless服务平台,今天小数再讲讲它的5大优势,在如缩短交付周期等功能上与DevOps&SRE不谋而合。


图片社交巨头Instagram面对流量爆增,通过Serverless完成自救。果然创业艰辛,而这也恰恰证明了Serveless架构逐渐成为主流技术是有道理的。


Instagram&Serverless


Serverless架构在IT行业蓄势待发,并非没有道理。尽管这是一个相对较新的技术,但已引起了广泛的关注,许多新技术专家指出,Serverless架构具有缩短交付时间,改善操作和安全实践等功能,以及创造出一种革命性的付费模式——按资源消耗付费。


2010年Instagram发布时,差点因其准备不足而无法成为下一个白手起家的社交媒体公司。


在短短的6个小时之内,暴增的流量超过了其在洛杉矶服务器所能承受的负载。


联合创始人Mike Krieger和Kevin Systrom被迫将本地服务器紧急迁移到Amazon的E2C云服务上,他们称之为心脏手术。也正是这个举措挽救了Instagram。


经过六年的快速发展,Serverless架构取得了巨大的成果,不止简单的将现有服务器迁移到云端帮助扩展和操作,还采用弹性计算这种新的方法来简化开发过程。为Uber、口袋妖怪GO、部落冲突、Airbnb和其他具有大量基数的应用及实时数据提供了必要的保障。


在苹果或者谷歌的游戏应用商店里,有超过400万个应想供用户选择,开发人员为了寻求竞争优势,逐步转向Serverless架构。游戏应用的开发成本很容易就到达6位数,但90%的付费应用每天收入不到1250美元。通过降低成本和内部复杂性,Serverless架构帮助开发者应对激烈竞争的市场,以及提供良好的用户体验。


例如,利用全球网络数据流,无需繁琐构建架构和维护服务器,为什么不这样做呢?


Serverless架构的秘密
对于开发者来说,Serverless架构可以将其服务器端应用程序分解成多个执行不同任务的函数,整个应用分为几个独立、松散耦合的组件,这些组件可以在任何规模上运行。


Serverless需要这些功能运行在并行的容器上,分别监控和缩放。这种新的体系结构提供了几个关键点,并解决了其他软件挑战性和伸缩性问题。


举个例子:实时过滤聊天评论。许多聊天应用的业务需求大都是每条信息必须经过过滤、解析或在交付给收件人之前进行管理。


通常的方法是每条消息首先会发送到服务器,解析并重新发布到聊天室,对于少量的同步用户可能有用,但若有100万用户的话,简单的聊天过滤问题就会变成分布式计算的噩梦。


同样的问题对于Serverless架构来说简直是无痛的,开发人员写一个过滤聊天信息的函数。Serverless将函数封装到容器中,可以在任意数量的服务器上监控、备份和分发。开发人员将所有聊天信息路由到程序,只需运行更多容器即可确保逻辑能在任何规模上运行。


Serverless架构的优势


无论是正在开发一个聊天应用,还是想成为下一个口袋妖怪GO,Serverless架构都是最好的选择。


〓 缩短交付时间


Serverless架构允许开发人员在极短时间内(数天、数小时)交付新的应用程序,而不是像以前一样需要几个星期或数月。在新的应用程序中,依赖于第三方API提供服务的例子很多,如认证(OAuth)、社交(Twitter)、地图(Mapbox)、人工智能(IBM的Watson)等等。


〓 增强可伸缩性


所有人都希望自己开发的应用成为下一个Facebook,但若梦想成真,它能够负载吗?当成功降临却没有准备好就更加令人遗憾。Serverless架构的体系不用有上述担忧,如某个在线培训APP,6个月内获取了4万用户,但一个服务器都没有用。


〓 降低成本


Serverless架构模式可以降低计算能力和人力资源方面的成本,如果不需要服务器,就不用花费时间重新造轮子、风险监测、图像处理、以及基础设施管理,操作成本更会直线下降。


〓 改善用户体验


用户不太关心基础设施,更注重的是功能和用户体验。Serverless架构允许团队将资源集中在用户体验上。例如:气象公司利用Serverless架构给种植者提供了丰富的界面去操作农场设备,并会提示相关操作改进。


〓 减少延迟及优化地理位置信息


应用规模能力取决于三个方面:用户数量、所在位置及网络延迟。现在应用要面向全球受众,因而产生延迟降低体验。在Serverless架构下,供应商在每个用户附近都有节点,大幅度降低了延迟,因此对每个用户都适用。如:Gett在全球范围内提供按需服务,因此它选择了Serverless架构来降低延迟,即时消息连接司机和乘客,以及流媒体的地理位置更新。


结语


从照片分享应用到农业数据仪表盘再到连接引擎,Serverless架构可以满足开发者的广泛需求。


随着数据负载的持续增长,期待Serverless架构通过降低成本、延迟、交付时间和复杂性,成为应用开发领域的主要技术。


关于Serverless架构,你还知道哪些其他的优势吗?

golang写的web application 怎么优雅的更新?

maxwell92 回复了问题 • 17 人关注 • 8 个回复 • 1488 次浏览 • 2017-06-29 13:26 • 来自相关话题

GOLANG使用Context实现传值、超时和取消

winlin 发表了文章 • 0 个评论 • 424 次浏览 • 2017-06-28 16:24 • 来自相关话题

GO1.7之后,新增了context.Context这个package,实现goroutine的管理。

Context基本的用法参考GOL... 查看全部

GO1.7之后,新增了context.Context这个package,实现goroutine的管理。


Context基本的用法参考GOLANG使用Context管理关联goroutine


实际上,Context还有个非常重要的作用,就是设置超时。比如,如果我们有个API是这样设计的:


type Packet interface {
encoding.BinaryMarshaler
encoding.BinaryUnmarshaler
}

type Stack struct {
}
func (v *Stack) Read(ctx context.Context) (pkt Packet, err error) {
return
}

一般使用是这样使用,创建context然后调用接口:


ctx,cancel := context.WithCancel(context.Background())
stack := &Stack{}
pkt,err := stack.Read(ctx)

那么,它本身就可以支持取消和超时,也就是用户如果需要取消,比如发送了SIGINT信号,程序需要退出,可以在收到信号后调用cancel


sc := make(chan os.Signal, 0)
signal.Notify(sc, syscall.SIGINT, syscall.SIGTERM)
go func() {
for range sc {
cancel()
}
}()

如果需要超时,这个API也不用改,只需要调用前设置超时时间:


ctx,cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
pkt,err := stack.Read(ctx)

如果一个程序在运行,比如Read在等待,那么在没有人工干预的情况下,那就应该自己运行就好了。而人工干预,也就是需要取消,比如要升级程序了,或者需要停止服务了,都属于这种取消操作。而超时,一般是系统的策略,因为不能一直等下去,就需要在一定时间没有反应时终止服务。实际上context这两个都能支持得很好,而且还不影响Read本身的逻辑,在Read中只需要关注context是否Done:


func (v *Stack) Read(ctx context.Context) (pkt Packet, err error) {
select {
// case <- dataChannel: // Parse packet from data channel.
case <- ctx.Done():
return nil,ctx.Err()
}
return
}

这是为何context被接纳成为标准库的包的缘故了吧,非常之强大和好用,而又非常简单。一行context,深藏功与名。


另外,Context还可以传递上下文的Key-Value对象,比如我们希望日志中,相关的goroutine都打印一个简化的CID,那么就可以用context.WithValue,参考go-oryx-lib/logger

为什么gRPC客户端不提供连接池?

elvin5 回复了问题 • 7 人关注 • 4 个回复 • 1564 次浏览 • 2017-06-26 10:15 • 来自相关话题

GOLANG如何避免字符串转义

winlin 发表了文章 • 0 个评论 • 314 次浏览 • 2017-06-23 17:41 • 来自相关话题

避免转义字符,例如造个json:

json.Unmarshal(`{"code":0, "data":{"server":"127.0.0.1:8080"}}`)查看全部
					

避免转义字符,例如造个json:


json.Unmarshal(`{"code":0, "data":{"server":"127.0.0.1:8080"}}`)

是不是太简单了点,但是我好像并不总是记得。