你如何理解后端开发

拿支付宝来举例，曾经的支付宝用户数并不多，一台服务器，一个数据库就可以支持所有的业务了。

当支付宝的用户越来越多的时候，一台服务器无法同时满足海量用户的需求，于是开始出现了多台服务器，多台服务器组成了一个集群，用户可以通过负载均衡的方式访问这些服务器，每个用户可能会访问到不同的机器上，这样子就达到了分流的效果，服务器的压力就会减小。

由于数据库需要保证数据的可靠性，万一某一台数据库挂了，并且没有备份的话，那么这个数据就无法访问了，这在大型系统中是不允许出现的，于是就有了数据库的主从部署。

但事实上，随着业务发展，数据库的压力也越来越大，主备部署并不能解决数据库访问性能的问题，于是乎我们需要进行分库分表，在数据库主备的基础上，我们会把一个数据量很大的表拆成多个表，并且把数据库请求分流到不同的数据上，比如说100个分库，100个分表，就相当于把一个数据表划分成10000个数据表。

此时又出现一个问题，如果一个数据库有多个备库，并且当主库挂掉的时候需要进行主从切换时，主备数据库之间的数据就可能发生不一致，而这也是分布式理论研究的问题之一。
其实负载均衡、分库分表都是分布式技术的一种实现，如果不想做分库分表，那还有什么办法能够减轻数据库访问的压力呢？于是缓存就出现了，缓存可以让服务器先把请求打到缓存上，由于缓存的数据一般在内存中，所以访问速度会非常快，这些请求无需经过数据库。

随着业务发展，缓存的单点压力也会比较大，于是乎分布式缓存就出现了，通常来说，缓存难以保证数据的可靠性，因为它们的数据可能会丢失，同时缓存只能存储一部分的数据，并不能解决所有问题。

所以当某些业务的请求量非常大的时候，光靠缓存也解决不了问题，此时我们还可以通过消息队列来帮我们解决大流量并发请求的问题。

我们可以通过消息队列来存储一部分的请求消息，然后根据我们服务器处理请求的能力，把消息再逐步取出来，接着去把这些消息逐渐地进行处理，这样就可以很好的解决高并发的问题。当然，前提是消息队列要保证消息存储的可靠性，这也是大部分消息队列都会保证的能力。

这些就是我对 Java 后端大概面貌的一个认识。