这篇文章给大家分享的是有关当Golang遇到高并发秒杀怎么办的内容。小编觉得挺实用的，因此分享给大家做个参考。一起跟随小编过来看看吧。
遇到GO语言也是偶尔的一次机会，工作上做架构相关的事情，对新发展比较火爆的语言肯定要关注下。就这样步入了GO语言的世界，GO给我带来了全新的体验;
一直做一件事情的人往往会被一件事情所困，开始实践GO语言的时候总感觉哪哪都别扭，特别是把结构体当成类，还有结构体的继承，写面向对想多了开始还真扭不过来。不过写的多了渐渐地也习惯了，甚至感觉越来越顺眼。
在熟悉了GO一段时间后，也停止了一会，脑子里一直在想着GO的简洁(代码风格一致，用起来简练不拖泥带水，部署极其简单，编译速度用快来形容)，能给项目系统和架构带来哪些改变。但是当时一时半会儿还真没想到有多大帮助，后来系统逐步开始用GO实现，用的多了慢慢地发现：
咦～，部署再也不要搭建依赖环境了(不部署环境发布，刚开始还真有点不习惯，总感觉少来点什么;
别人写的代码看着也没有抵触心理，虽然说有的代码不是自己写的，仔细阅读的时候就感觉像是自己写的，写JAVA 和PHP的时候 阅读代码哪是从内心拒绝的;
开发某个微服务接口一切变得简单了，写个main，写个接口，提交，秒秒种就上线了～;
上面主要说了自己和GO的相遇还有GO给我带来的初步影响，就在某天晚上我脑袋里突然蹦出一个想法，GO语言用简洁带来诸多提升，从事的架构系统是否也能利用GO来简化，降低系统复杂度?这个想法从蹦出来，就一直在我脑袋里徘徊。回想刚开始从事架构相关事情的时候，一看到讲中间件有什么原理，有什么优化能提高性能就非常兴奋，埋头苦研直到自己感觉掌握(当然现在也要)，然后就信誓旦旦的用到系统中，感觉系统架构用中间件组件越多越好，越多越显得自己做的架构有多厉害。但是随着越做越久你就会发现，系统能用就行，不能为了架构而架构。从传统技术栈上做减法同样需要深厚的功底，因为只有充分知道技术原理才能替换，也才敢想敢干，不出问题。常言道：“条条大陆通罗马”，从个人较角度讲架构要适合当时的业务，达到用尽可能少的代价完成尽可能多的事情就算达到架构设计的目标了，就比如消耗服务器资源相同情况下能支撑好几倍甚至好几十倍的请求，达到相同请求量的情况下，实现和部署非常简单可操作等。GO的思想这段时间就一直这么潜移默化地影响这我。
直到我们公司决定做微服务，刚开始我们用java做微服务。后来想了下其它语言是否也能做微服务，自然而然的就想到了GO，经过一番折腾后感觉还可以，就用GO开始写点微服务，写着写着就发现Golang 写微服务还挺顺手，效率那个高啊，也不用封装tomcat(这东西放jar包里，感觉特别不合适)，二进制不用系统依赖都能在docker里面跑(不信你试试)，就这样打心底来说越来越喜欢GO，后续的系统啥的也想用GO重构(写多了java多了遇到这么方便的真是感觉发现了春天)GO已经深入的影响了对系统的架构的看法。
但究竟什么是架构，架构师又是这么炼成的 ?在这里分享下架构师炼成的八段艰辛：
第一段：搬砖分为能办好砖和只会搬砖(有一批人留在了搬砖上，剩下的继续发展);
第二段：能搬砖的可以分为要了解原理的和编程就是搬砖的;
第三段：了解原理的又分为不断研究的和一知半解的;
第四段：不断研究也能分成两种研究深入有广度和蜻蜓点水没广度的;
第五段：有深度有广度的又分为纯技术型和业务型(开始分化);
第六段：业务型要求有良好沟通，对系统和需求有一定设计把控能力的;
第七段：这层很容易出现单纯使用堆中间件搭出“架构”系统的(初级架构师);
第八段：这层很重要的一点，考虑问题足够细致、全面、善于沟通。做底层实现，理解底层原理，从业务，研发，测试，部署，维护升级多角度出发，因地制宜搭出的“架构”是为了开发效率，为了运行效率，为了开发质量，为了业务灵活和运行稳定，为了维护方便等等这样的人，可称为架构师(有这方面经验的回想下，有多少架构是表面上看着漂亮，实际用着难受的)。
在做秒杀系统的时候，刚开始想到也最容易想到的传统技术栈就是，分布式session，Redis集群，分布式缓存，nginx反向代理nginx深层优化，机器优化，消息队列。没错Cap老师当年也是想到这些，也认为这些“成熟”的技术能应用到我们秒杀系统中没问题，况且公司内部讨论都感觉这些没问题。而且做了深入的研究比如：
