服务器的基本配置

要组建一个网站服务器，服务器系统是必需的。现在基本上家用电脑都安装了WINDOWS系统，WINDOW系统自身带有IIS服务器，所以一般不必要去另外安装服务器了。只需要启动IIS服务器即可用于存放ASP程序网站了。如果要存放PHP程序网站需要搭建PHP+MYSQL环境

第二步：网站域名与服务器的动态解析

家用电脑一般的上网方式为“猫”或者路由器，那么每台电脑的IP地址是不断变化的。每次我们重启一下“猫”或者路由器就是生成一个新的IP地址。

如果我们要用自己的电脑做服务器来做网站就必须让网站域名解析到服务器IP上，可现在我们的电脑的IP是不断变化的，怎么解析呢？这时就需要使用“动态解析”了。“动态解析”就需要电脑先安装一个“动态解析器”。

1、首先应该配置服务器的外部接口。你应该已经知道如何做到这一点，并且可能已经完成了。如果你不这样做，那么现在就这样做。

2、现在我们调出内部接口。根据我们选择的数字，服务器的内部接口是19216840254。所以我们必须配置该接口。

3、设置路线。 我们现在可以与当地网络上的机器通信，但我们无法访问其他内部网络。这需要更多的代码行。

4、任何发往19216800网络的流量都应该输出eth1，并且它应该交给思科。我们的本地网络的流量仍然可以达到应有的位置，因为路由表按网络掩码的大小排序。如果我们在我们的网络中有其他内部网络，我们将为每个网络提供如上所述的线路。

5、现在我们可以访问我们可能需要的每台机器，我们需要编写允许或拒绝通过***服务器访问的防火墙过滤规则。

6、对于家庭用户来说，一切都可以在这里工作。但是对于远程办公室，我们需要做一些路由。首先，我们需要告诉主路由器或思科，远程办公室是***服务器的后面。因此，请指定Cisco上的路由，告知它将发往远程办公室的流量发送到***服务器。现在，我们必须告诉***服务器如何处理发往远程办公室的流量。

7、为此，我们在服务器上运行 route命令。唯一的问题是为了路线命令工作，链接必须是up，如果它关闭，路由将丢失。解决方案是在客户端连接时添加路由，或者更简单地，经常运行路由命令，因为运行它不是必要的问题。

大型分布式架构都是靠多种语言和工具共同分工合作实现的。

不是一两种工具或者语言能实现的，如果专指php那是没有意义的，因为php本身只是一个单进程的东东，更别说分布式。

大规模的web应用以及分布式架构主要在于服务器的整体架构：

1、web服务集群；

2、数据库集群；

3、分布式缓存；

php充其量只是实现其中一个节点的某个具体的web应用。

SD框架支持长连接协议TCP，WebSocket，短连接协议HTTP，以及UDP。

通过配置开放不同的端口开发者可以轻松管理不同的协议，并且可以共用一套业务代码，当然你可以通过智能路由进行代码的隔离。

长连接可以配置不同的数据传输协议，比如二进制协议文本协议等等，通过框架提供的封装器解包器接口可以自定义各种各种的协议封装，并且各种协议之间可以自动转换，比如你通过广播发送一个信息，该信息流向不同客户端，客户端间采用不同协议，那么框架会根据不同的端口自动转换不同的协议封装。

也可以通过Http给所有长连接客户端发送推送消息，类似这种混合协议协作的业务在SD框架上会异常简单。

扩展资料：

普通的Web开发，常用的模式就是用户登录之后，登录状态信息保存在Session中，用户一些常用的热数据保存在文件缓存中，用户上传的附件信息保存在Web服务器的某个目录上。这种方式对于一般的Web应用，使用很方便，完全能够胜任。但是对于高并发的企业级网站，就应付不了了。需要采用Web集群实现负载均衡。

使用Web集群方式部署之后，首要调整的就是用户状态信息与附件信息。用户状态不能再保存到Session中，缓存也不能用本地Web服务器的文件缓存，以及附件，也不能保存在Web服务器上了。因为要保证集群里面的各个Web服务器，状态完全一致。

因此，需要将用户状态、缓存等保存到专用的缓存服务器，比如Memcache。附件需要保存到云存储中，比如七牛云存储、阿里云存储、腾讯云存储等。

SD框架内大多数的对象都使用了对象池技术，对象池技术有利于系统内存的稳定，减少GC的次数，提高系统的运行效率，事实证明对象池对系统稳定做出了极大的贡献。

开发者也可以使用这一套对象池技术，增加对对象的复用，减少GC和NEW的频率，对系统毛刺现象和内存泄露方面都有很大的稳定性提升。

参考资料：

缘起：受@萧田国 萧总邀请，上周五晚上在“高效运维1号群”内分享了《58同城数据库软件架构设计与实践》（这个topic今年在数据库大会上分享过），应组织方要求，发出纪要。

一、基本概念

二、数据库架构设计思路

（1）可用性

（2）读性能

（3）一致性

（4）扩展性

一、基本概念

概念一“单库”

概念二“分片”

分片解决的是“数据量太大”的问题，也就是通常说的“水平切分”。

一旦引入分片，势必有“数据路由”的概念，哪个数据访问哪个库。

路由规则通常有3种方法：

（1）范围：range

优点：简单，容易扩展

缺点：各库压力不均（新号段更活跃）

（2）哈希：hash

优点：简单，数据均衡，负载均匀

缺点：迁移麻烦（2库扩3库数据要迁移）

（3）路由服务：router-config-server

优点：灵活性强，业务与路由算法解耦

缺点：每次访问数据库前多一次查询

大部分互联网公司采用的方案二：哈希分库，哈希路由

概念三“分组”

分组解决“可用性”问题，分组通常通过主从复制的方式实现。

互联网公司数据库实际软件架构是：又分片，又分组（如下图）

二、数据库架构设计思路

数据库软件架构师平时设计些什么东西呢？至少要考虑以下四点：

（1）如何保证数据可用性

（2）如何提高数据库读性能（大部分应用读多写少，读会先成为瓶颈）

（3）如何保证一致性

（4）如何提高扩展性

21如何保证数据的可用性？

解决可用性问题的思路是=>冗余

如何保证站点的可用性？复制站点，冗余站点

如何保证服务的可用性？复制服务，冗余服务

如何保证数据的可用性？复制数据，冗余数据

数据的冗余，会带来一个副作用=>引发一致性问题（先不说一致性问题，先说可用性）

如何保证数据库“读”高可用？

冗余读库

冗余读库带来的副作用？读写有延时，可能不一致

上面这个图是很多互联网公司mysql的架构，写仍然是单点，不能保证写高可用。

如何保证数据库“写”高可用？

冗余写库

采用双主互备的方式，可以冗余写库

带来的副作用？双写同步，数据可能冲突（例如“自增id”同步冲突）,如何解决同步冲突，有两种常见解决方案：

（1）两个写库使用不同的初始值，相同的步长来增加id：1写库的id为0,2,4,6；2写库的id为1,3,5,7

（2）不使用数据的id，业务层自己生成唯一的id，保证数据不冲突

58同城没有使用上述两种架构来做读写的“高可用”，58同城采用的是“双主当主从用”的方式：

仍是双主，但只有一个主提供服务（读+写），另一个主是“shadow-master”，只用来保证高可用，平时不提供服务。

master挂了，shadow-master顶上（vip漂移，对业务层透明，不需要人工介入）

这种方式的好处：

1）读写没有延时

2）读写高可用

不足：

1）不能通过加从库的方式扩展读性能

2）资源利用率为50%，一台冗余主没有提供服务

那如何提高读性能呢？进入第二个话题，如何提供读性能。

22如何扩展读性能？

提高读性能的方式大致有三种，第一种是建立索引。这种方式不展开，要提到的一点是，不同的库可以建立不同的索引。

写库不建立索引；

线上读库建立线上访问索引，例如uid；

线下读库建立线下访问索引，例如time；

第二种扩充读性能的方式是，增加从库，这种方法大家用的比较多，但是，存在两个缺点：

（1）从库越多，同步越慢

（2）同步越慢，数据不一致窗口越大（不一致后面说，还是先说读性能的提高）

58同城没有采用这种方法提高数据库读性能（没有从库），采用的是增加缓存。常见的缓存架构如下：

上游是业务应用，下游是主库，从库（读写分离），缓存。

58同城的玩法是：服务+数据库+缓存一套

业务层不直接面向db和cache，服务层屏蔽了底层db、cache的复杂性。为什么要引入服务层，今天不展开，58采用了“服务+数据库+缓存一套”的方式提供数据访问，用cache提高读性能。

不管采用主从的方式扩展读性能，还是缓存的方式扩展读性能，数据都要复制多份（主+从，db+cache），一定会引发一致性问题。

23如何保证一致性？

主从数据库的一致性，通常有两种解决方案：

（1）中间件

如果某一个key有写操作，在不一致时间窗口内，中间件会将这个key的读操作也路由到主库上。

这个方案的缺点是，数据库中间件的门槛较高（百度，腾讯，阿里，360等一些公司有，当然58也有）

（2）强制读主

58的“双主当主从用”的架构，不存在主从不一致的问题。

第二类不一致，是db与缓存间的不一致

常见的缓存架构如上，此时写操作的顺序是：

（1）淘汰cache

（2）写数据库

读操作的顺序是：

（1）读cache，如果cache hit则返回

（2）如果cache miss，则读从库

（3）读从库后，将数据放回cache

在一些异常时序情况下，有可能从从库读到旧数据（同步还没有完成），旧数据入cache后，数据会长期不一致。

解决办法是“缓存双淘汰”，写操作时序升级为：

（1）淘汰cache

（2）写数据库

（3）在经验“主从同步延时窗口时间”后，再次发起一个异步淘汰cache的请求

这样，即使有脏数据如cache，一个小的时间窗口之后，脏数据还是会被淘汰。带来的代价是，多引入一次读miss（成本可以忽略）。

除此之外，58同城的最佳实践之一是：建议为所有cache中的item设置一个超时时间。

说完一致性，最后一个话题是扩展性。

24如何提高数据库的扩展性？

原来用hash的方式路由，分为2个库，数据量还是太大，要分为3个库，势必需要进行数据迁移，58同城有一个很帅气的“数据库秒级扩容”方案。

如何秒级扩容？

首先，我们不做2库变3库的扩容，我们做2库变4库（库加倍）的扩容（未来4->8->16）

服务+数据库是一套（省去了缓存）

数据库采用“双主”的模式。

扩容步骤：

第一步，将一个主库提升

第二步，修改配置，2库变4库（原来MOD2，现在配置修改后MOD4）

扩容完成

原MOD2为偶的部分，现在会MOD4余0或者2

原MOD2为奇的部分，现在会MOD4余1或者3

数据不需要迁移，同时，双主互相同步，一遍是余0，一边余2，两边数据同步也不会冲突，秒级完成扩容！

最后，要做一些收尾工作：

（1）将旧的双主同步解除

（2）增加新的双主（双主是保证可用性的，shadow-master平时不提供服务）

（3）删除多余的数据（余0的主，可以将余2的数据删除掉）

这样，秒级别内，我们就完成了2库变4库的扩展。

OK，今天主要分享了58同城，数据库软件架构上：

（1）如何保证数据可用性

（2）如何提高数据库读性能

（3）如何保证数据一致性

（4）如何进行秒级扩容

希望大家有收获，谢谢大家！

===完===

转自58沈剑 架构师之路

转载数据库软件架构设计些什么

标签：个数mda设计timeottitemlogs##key