江苏龙网

  1. 首页 > 生活 > >

电商项目怎样处理或用啥技术解决高负载、高并发、高可用性问题( 五 )


在Actor内部是线性处理（单线程）的，Actor之间以消息方式交互，也就是不允许Actor之间共享数据，没有共享，就无需用锁，这就避免了锁带来的各种副作用。
Actor的创建和new一个对象没有啥区别，很快、很小，不像线程的创建又慢又耗资源；Actor的调度也不像线程会导致操作系统上下文切换（主要是各种寄存器的保存、恢复），所以调度的消耗也很小。
Actor还有一个有点争议的优点，Actor模型更接近现实世界，现实世界也是分布式的、异步的、基于消息的、尤其Actor对于异常（失败）的处理、自愈、监控等都更符合现实世界的逻辑。
但是这个优点改变了编程的思维习惯，我们目前大部分编程思维习惯其实是和现实世界有很多差异的（这个回头再细说），一般来讲，改变我们思维习惯的事情，阻力总是超乎我们的想象。
\u0026gt;\u0026gt;\u0026gt;\u0026gt;0x12 CSP模型
Golang在语言层面支持CSP模型，CSP模型和Actor模型的一个感官上的区别是在CSP模型里面，生产者（消息发送方）和消费者（消息接收方）是完全松耦合的，生产者完全不知道消费者的存在，但是在Actor模型里面，生产者必须知道消费者，否则没办法发送消息。
CSP模型类似于我们在多线程里面提到的生产者-消费者模型，核心的区别我觉得在于CSP模型里面有类似绿色线程（green thread）的东西，绿色线程在Golang里面叫做协程，协程同样是个非常轻量级的调度单元，可以快速创建而且资源占用很低。
Actor在某种程度上需要改变我们的思维方式，而CSP模型貌似没有那么大动静，更容易被现在的开发人员接受，都说Golang是工程化的语言，在Actor和CSP的选择上，也可以看到这种体现。
\u0026gt;\u0026gt;\u0026gt;\u0026gt;0x13 多样世界
除了消息传递模型，还有事件驱动模型、函数式模型。事件驱动模型类似于观察者模式，在Actor模型里面，消息的生产者必须知道消费者才能发送消息，而在事件驱动模型里面，事件的消费者必须知道消息的生产者才能注册事件处理逻辑。
Akka里消费者可以跨网络，事件驱动模型的具体实现如Vertx里，消费者也可以订阅跨网络的事件，从这个角度看，大家都在取长补短。

■网友
我给你一句话就解决了，软件架构师、系统工程师还能拿那么多钱吗……这个全都是结合业务设计的，不同业务适合的技术也不一样，跟架构师个人喜好也有关系。
■网友
看到某营销号一堆说法没法忍，那样的话，下次回答这类问题是不是把那基本神书贴上来就好了。

对于高并发的项目，我们解决的是流量和吞吐量之间的问题。当系统的吞吐量 \u0026gt; 流量的时候，这个时候一般是不会遇到问题的。所以，解决此类问题有两件事情要做：
扩大吞吐量 扩大吞吐量有两个思路，传统上都是scale up，其实就是堆牛逼的机器，早期IOE就是这一套，但是这个思路后面遇到一些问题。一个是单机硬件处理能力的增长速度赶不上互联网流量增长的速度，比如阿里巴巴。另一个是很多公司高峰流量和平峰流量相差几十倍，如果你提升机器性能，那么在平峰的时候就会有极大的浪费。所以现在更流行scale out的策略，这里多说一句，有scale out并不代表scale up不重要.
scale out个人理解有两个层面来做,一个是计算层面,一个是存储层面.
在计算层面,像nginx的反向代理,微服务都是为这个服务的,就是说,我可以动态扩容.当然,这里一般都有需要一台协调机器(反向代理就有一台代理机器,微服务还有一个register的角色),当业务机器扩容到一定级别的时候,这些协调的角色就会成为瓶颈.所以后面产生了类似lvs,dpvs之类的提升协调者单机处理能力的框架,也产生了gslb/dns负载均衡等方案,从流量的源头(客户端)就把流量分散到不同的接入服务器上,解决接入服务器单个节点的瓶颈问题.
在存储层面,目前大部分公司都是靠业务分库分表来解决这类问题的,现在也开始有一些公司直接使用分布式数据库,比如阿里的ob,现在的tidb,当然这一块的始祖应该还是Google,有兴趣可以去了解一下G三篇和spanner。


推荐阅读


上一篇：作为互联网创业者，要有哪些技术常识

下一篇：国内三流211大学，本硕都物理专业，研究生毕业投身互联网行业，去做编程相关的工作，有啥要交代的吗