13518219792
不可以，完全没有可比性。
舞钢网站建设公司成都创新互联,舞钢网站设计制作，有大型网站制作公司丰富经验。已为舞钢近千家提供企业网站建设服务。企业网站搭建\成都外贸网站建设要多少钱，请找那个售后服务好的舞钢做网站的公司定做！
Golang的优势是开发速度，C可以自由、精准的操控内存。
拿string类型举个栗子：
1、修改字符串：
golang：需要分配新内存，然后进行内存copy。
c：可直接修改，可realloc。
2、存一段data：
golang：使用[]byte类型，[]byte转成string需要进行内存拷贝(排除掉利用指针进行类型转换的情况)。
c：直接用char[]，可读可写。
golang中为了语言的安全性，类似的这种限制有很多，牺牲了一部分性能。但golang的优势也是显而易见的，goroutine、chan都很好用，而c则需要自己进行进程、线程的管控。
本项目用于移动端的数据统计，项目地址： 。开源的数据统计countly做的很好，但是基础免费版的功能实在不够看，因此我就决定用go语言来写了这个项目，一来可以在实践中学习go语言，二来也可以开发功能完整的开源平台。该项目正在开发中，欢迎有兴趣的gopher一起参与。
数据存储方面使用的是mongodb。由于数据统计业务几乎不涉及到事务以及严格的一致性场景，而且mongodb的自动分片功能可以支撑较大的数据量。使用大数据的存储组件的话就太过于重了。因此选用mongodb。
业务逻辑整体基于事件的发布订阅。当收到客户端请求， frontend 会对请求数据进行处理，然后发布响应的事件。 backend 收到事件后进行统计处理。
后台展示基于Vue-Admin-Template开发，本人前端能力基本就是依葫芦画瓢，希望有前端大神来开发后台页面，项目地址:
目前客户端API仅有2个。一个是上报 openApp 打开APP时间，一个是上报 usageTime 一次启动使用时长事件。SDK方面也需要移动端的大神开发，感兴趣的大佬可以一起开发。
下面放一点后台页面的效果图：
GoAnalytics是基于go实现的一个数据统计平台，用于统计移动端的数据指标，比如启动次数、用户增长、活跃用户、留存等指标分析。前端数据展示项目是 goanalytics-web 。目前正在积极开发中，欢迎提交新的需求和pull request。
Go版本需要支持module，本地开发测试
cmd/goanalytics_kafka 和 goanalytics_rmq 是分别基于 kafka 和 rocketmq 的发布订阅功能做的数据发布
和订阅处理，横向扩展能力比 local 高。另外由于 rocketmq 还没有原生基于 go 的客户端（原生客户端正在开发中
2.0.0 road map )，可能会存在问题。
项目结构
├── README.md
├── api
│ ├── authentication 用户认证、管理API
│ ├── middlewares GIN 中间件
│ └── router API route
├── cmd
│ ├── account 生成admin账号命令
│ ├── analytic_local 不依赖消息系统的goanalytics
│ ├── goanalytics_kafka 基于kafak的goanalytics
│ ├── goanalytics_rmq 基于rocketmq的goanalytics
│ └── test_data 生成测试数据命令
├── common
│ └── data.go
├── conf 配置
│ └── conf.go
├── event
│ ├── codec 数据编解码
│ └── pubsub 消息发布订阅
├── go.mod
├── go.sum
├── metric 所有的统计指标在这里实现
│ ├── init.go
│ └── user 用户相关指标的实现
├── schedule
│ └── schedule.go 定时任务调度
├── storage 存储模块
│ ├── counter.go 计数器接口
│ ├── data.go
│ └── mongodb 基于mongodb实现的存储及计数器
└── utils
├── date.go
├── date_test.go
├── errors.go
└── key.go
很多朋友可能知道Go语言的优势在哪，却不知道Go语言适合用于哪些地方。
1、 Go语言作为服务器编程语言，很适合处理日志、数据打包、虚拟机处理、文件系统、分布式系统、数据库代理等；网络编程方面。Go语言广泛应用于Web应用、API应用、下载应用等；除此之外，Go语言还可用于内存数据库和云平台领域，目前国外很多云平台都是采用Go开发。
2、 其实Go语言主要用作服务器端开发。其定位是用来开发"大型软件"的，适合于很多程序员一起开发大型软件，并且开发周期长，支持云计算的网络服务。Go语言能够让程序员快速开发，并且在软件不断的增长过程中，它能让程序员更容易地进行维护和修改。它融合了传统编译型语言的高效性和脚本语言的易用性和富于表达性。
3、 Go语言成功案例。Nsq：Nsq是由Go语言开发的高性能、高可用消息队列系统，性能非常高，每天能处理数十亿条的消息；
4、 Docker：基于lxc的一个虚拟打包工具，能够实现PAAS平台的组建。
5、 Packer：用来生成不同平台的镜像文件，例如VM、vbox、AWS等，作者是vagrant的作者
6、 Skynet：分布式调度框架。
7、 Doozer：分布式同步工具，类似ZooKeeper。
8、 Heka：mazila开源的日志处理系统。
9、 Cbfs：couchbase开源的分布式文件系统。
10、 Tsuru：开源的PAAS平台，和SAE实现的功能一模一样。
11、 Groupcache：memcahe作者写的用于Google下载系统的缓存系统。
12、 God：类似redis的缓存系统，但是支持分布式和扩展性。
13、 Gor：网络流量抓包和重放工具。
以上的就是关于go语言能做什么的内容介绍了。
有个服务会大量使用延迟消息，进行事件处理。随着业务量不断上涨。在晚间、节假日等流量高峰期消息延迟消息队列限流会导致事件丢失，影响业务。与下游沟通后给上调到了最大限流值，问题依然存在，于是决定自己搞一套降级方案。
下游服务触发限流时，能降级部分流量到本地延迟队列，把业务损失降到最低。
本地延迟队列承接部分mq流量
流程如下：
1. 使用zset 存储延迟消息，其中：score为执行时间，value为消息体
2. 启动协程轮询zset，获取score最小的10条数据，协程执行间隔时间xs
如果最小分值小于等于当前时间戳，则发送消息
若最小分值大于当前时间戳，sleep等待执行
需要对key进行hash，打散到多个分片中，避免大key和热key问题，官方大key定义
因此，需保证每个key中value数量n5000，单个value大小不超过 10240/n kb
假设承接10w qps，如何处理？
10w qps延迟120s时，最开始消息队列会积累100000*120=12000000条消息
假如每条消息大小500b，需占用存储6000000kb = 6000Mb = 6GB
为避免大key问题，每个zset存放4000个元素，需要哈希到3000（3000是key的数量，可配置）个zset中。
整个集群假设500台实例，每个处理qps平均在200左右。
单实例消费能力计算：
遍历每个zset，针对每个zset起goroutine处理，此示例中需要 起3000个
但是每秒能处理成功的只有200个，其他都在空跑
综上：
将redis key分片数n和每次处理的消息数m进行动态配置，便于调整
当流量上涨时，调大分片数n和单实例单分片并发数m即可，假如消费间隔200ms，集群处理能力为n*m*5 qps
n = (qps * 120) / 4000
若qps=q，则计算公式如下
zadd = q
zRange = 500 * 5 * n / 500
zRemove = q
setNx = 500 * 5 * n
若10w qps，则
读qps = 15000 + 500*3000*5 =7515000，写 20w
pros
redis 读写性能好，可支持较大并发量，zrange可直接取出到达执行时间的消息
cons
redis 大key问题导致对数据量有一定的限制
分片数量扩缩容会漏消费，会导致事件丢失，业务有损
key分片数量过多时，redis读写压力较大
机器资源浪费，3000个协程，单实例同一秒只有200个针对处理，其他都在空跑
流程如下：
使用带缓冲的channel来实现延迟队列，channel中存放的数据为消息体（包括执行时间），channel能保证先进先出
从channel中取出数据后，判断是否到达执行时间
到达，同步发送mq
未到达，sleep 剩余执行时间，然后再次执行
从channel读出的数据如果未到达执行时间，无法再次放入channel中，需要协程sleep（执行时间-当前时间）
10w qps延迟120s时，最开始消息队列会积累100000*120=12000000条消息，假设每条消息大小500b，需要6G存储空间
channel 大小 = （qps*120）/ c , c=集群实例数，c=500 = channel大小为24000，占用12M内存
要处理10w qps，分摊到每个机器的处理速度为 100000/500 = 200，假设单协程处理10qps，开20个即可。
pros：
本地存储，相比redis，读写速度更快；协程数量少，开销低；资源利用率较方案一高
cons：
稳定性不如redis，实例故障可能导致数据丢失；worker池和channel扩缩容依赖服务重启，成本高速度慢
综上，我们以10w qps为例，对比两种方案在以下指标差异，选择方案二。
附上demo
