服务器是干什么的？和数据库有什么区别

服务器是提供计算服务的设备。服务器的构成包括处理器、硬盘、内存、系统总线等，和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

区别

1、从性质上看：

数据库是可以运行在服务器上的软件。服务器是硬件，服务器安上了数据库应用程序后可以变成数据库服务器。

2、从功能上看：

数据库是可以从数据库是按照数据结构来组织、存储和管理数据的仓库而服务器是用于数据计算和处理的硬件。用来存放客户请求并给出回应的硬件。

扩展资料：

服务器在网络中为其它客户机（如PC机、智能手机、ATM等终端甚至是火车系统等大型设备）提供计算或者应用服务。服务器具有高速的CPU运算能力、长时间的可靠运行、强大的I/O外部数据吞吐能力以及更好的扩展性。

根据服务器所提供的服务，一般来说服务器都具备承担响应服务请求、承担服务、保障服务的能力。服务器作为电子设备，其内部的结构十分的复杂，但与普通的计算机内部结构相差不大，如：cpu、硬盘、内存，系统、系统总线等。

服务器要保证数据安全，首先要勤打补丁，windows系统是通过高手的不断应用发现漏洞的，补丁就是补漏洞；其次要安装正规的杀毒软件，一定要服务器版的杀毒软件并保证杀毒软件病毒库样本更新到最新，这样一般的渗入网络攻击就可以防范，第三，根绝服务器的用途，封锁一些不常用的端口，使外部攻击无门可入；第四，安装网络看门狗，监控一些常用的端口，设置一些安全的策略；最主要的一点是第五要加强服务器用户的培训教育，防范内鬼，我们知道，防火墙是防范外部的攻击，防水墙才是防范内鬼的。完善服务器日志，加强对服务器资源的审计。服务器安全是一项长期的工作，不可能是一劳永逸的。

前言:

本文总结了iOS客户端与服务器进行交互时，采用 RESTful API + Json 的交互方式，针对不 同的数据形式以及不同的解析方法，如有不足之处，欢迎指正。

先了解一下相关的基本概念。

HTTP通信:

即使用HTTP协议进行通信，工作原理是客户端向服务器端发送一条HTTP请求，服务器收到之后先 解析客户端的请求，之后会返回数据给客户端，然后客户端再对这些数据进行解析和处理。HTTP 连接采取的是“请求—响应”方式，即在请求时建立连接通道，当客户端像服务器端发送请求时，服 务器端才能向客户端发送数据。

Socket通信:Socket又称套接字，在程序内部提供了与外界通信的端口，即端口通信。通过建立 socket连接，可为通信双方的数据传输传提供通道。Socket的主要特点有数据丢失率低，使用简 单且易于移植。Socket类似于peer to peer的连接，一方可随时向另一方喊话。

小结:HTTP和Socket都是基于TCP协议的。使用两种通信方式的情况是: 使用HTTP的情况:双方不需要时刻保持连接在线，比如客户端资源的获取、文件上传等。

使用UDP的情况:大部分即时通讯应用(QQ、微信)、聊天室、苹果APNs等。

主要有四种:

数据流

1从web服务器响应到手机终端的数据 一般打包在一个字节数组中，这个字节数据中包含了不同的 数据类型，客端端采取Java数据流和过虑流的方式从字节数组中取出各种类型的数据。

这种交互方式我在学习iOS之初用过，实际项目中并没有发现哪家公司在用。这种方式了扩展 了iOS平台在访问Web服务器进行交互时的解析数据能力，仅供研究学习。

2XML Webservice的标准数据格式。 Protocol Buffers

3Protocol Buffers 是一种轻便高效的结构化数据存储格式，支持跨平台。它很适合做数据存储或 RPC 数据交换格式。比 JSON 最大的优点就是传输的时候数据体积可以压缩很小，传输效率比较 高。本人在这个在项目中没有用到过。

4JSON

JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。 易于人阅读和编写。同时也易于机器解析和生成。毫无疑问，大家最常用。

本文重点会介绍关于Json数据格式 的常用格式。

Json数据格式 的采用，根据业务情况，一般是团队中的共识。技术的迭代更新，到后期基本都会考虑多 个平台的通用性、可移植性和可读性。比如 我们开发团队，有移动端开发(Android、iOS)、前端开发 (H5开发)和后台开发(golang开发)。

关于服务器的开发规范，我们先来了解一下。

服务器开发规范 我们采用的是 RESTful ， RESTful 是目前最流流行的 API设计规范，用于web数据接

口的设计。

• 面面向资源(URI)，具有解释性;

• 行为(GET / POST / PUT / PATCH / DELETE)与资源(URI)分离，更更加轻量量;

• 数据描述简单，使用用JSON、XML、Protocol Buffers即可全覆盖， 主要使用用JSON;

它的核心原则是定义用少量方法就能操作的命名资源。资源和方法可视为API的 和动词。

• GET :读取(Read)

• POST :新建(Create)

• PUT :更新(Update)，通常是全部更更新

• PATCH :更新(Update)，通常是部分更更新

• DELETE :删除(Delete)

项目搭建之始，客户端和服务器一般用 Get 和Post的方式来交互，随着业务的演进和技术的规范迭代， 到后期我们都得按规范来。于是 我们采用了上述几种方式来设计服务器接口，相应地，移动端的请求方 式也得与之对应。

至此，不在赘述 RESTful API 的设计规范，可自行百度了解更多。

接口的数据一般都采用JSON格式进行传输，不过，需要注意的是，JSON的值只有六种数据类型:

•Number:整数或浮点数

•String:字符串

•Boolean:true 或 false

•Array:数组包含在方括号 [] 中

•Object:对象包含在大括号 {} 中

•Null:空类型

传输的数据类型不能超过这六种数据类型,不能用Date数据类型，不同的解析库解析方式不同，可能会 导致异常，如果遇到日期的数据，最好的方式就是使用毫秒数表示日期。

本文总结了iOS与服务器的交互方式和数据类型，并总结了在实际项目的简单运用。数据格式的运

用场景远不止上面提到的几种场景，后期会持续完善，如有不足之处，欢迎指出。

  怎么保护你在服务器里的数据呢？  

  第一，建立独立硬盘。它的空间利用率和读写速度都很高，但容错率是零，任何一块硬盘出错都会导致数据丢失。要想容错，就必须把ABCD都复制一份，分别存储在两个硬盘里，互为备份。这安全性最高。就算一块硬盘发生故障，数据依然完整，但代价就是牺牲了空间利用率和读取速度。

  第二，组成复合阵列。如今的服务器大多都会选择阵列作为容错方案。同时，一旦某个硬盘出现故障，服务器就会自动激活空白硬盘，写入备份数据，进行恢复重建，这个过程叫热备份。

  第三，准备紧急电源防止断电。更大的风险往往来自于服务器外部，比  故障导致三天之内所有玩家的游戏数据全部丢失，无法挽回，最终只能调取更早的备份数据，把游戏内容回档至事故发生之前，让所有玩家前功尽弃。

  第四，进行冷备份。最简单的容灾方法是冷备份，也就是在拷贝数据后不接电也不联网，它的主要作用就是存档，以防万一。但不同存储介质的寿命不同，所以用冷备份容灾时，维持适宜的环境温度和湿度，避免服务器还没坏，冷备份就先报废了的情况。  

  第五，建立多个数据中心。相互连通，互相备份。目前常用的商用容灾方案是两地三中心加双活，也就是一处生产数据中心、一处同城灾备中心、一处异地灾备中心同时建设，并且保证至少两个数据中心同时处于运行状态。

  对于金融服务公司而言，数据容灾方案能在关键时刻决定企业的生死存亡。当然了，并不是所有的互联网公司的服务器都有如此高级别的容错容灾能力，除了数据安全，服务器的容量、成本、运行效率也都是厂商们考虑的因素。