高性能服务器是如何实现的

注意：正常情况下数组的 prepend 操作的时间复杂度是 O(n) ，但是可以进行特殊优化到 O(1)。采用的方式是申请稍微大一些的内存空间，然后在数组开始预留一部分空间，然后 prepend 的操作则是把头下标前移一个位置即可。

跳表 Skip List

前面回顾了 Array 和 Linked List 的两种结构的时间复杂度，有一种情况下链表它的速度在 O(n) 这一块，就会觉得不太够用，我们来看一下这种情况指的是什么?

链表元素有序的时候
 

前言

在这里我们先回忆一下普通链表的时间复杂度，可以看到除了 look up 操作是 O(n) 的，其他操作都是 O(1) 的时间复杂度。也就是说你需要随机访问里面的任何一个元素的话，它的时间复杂度平均值是 O(n) 的，这也就是链表它的问题所在。从这里可以看到并没有所谓完美的一种数据结构，如果完美那就不需要 Array 或者 LInked List 这两个数据结构并存了，就直接使用最牛逼的数据结构即可。所以相当于各有优劣，看你的使用场景在什么地方，作为完整性比较，我这里把两种时间复杂度都列出来。

Linked List 的时间复杂度
 

 AppId机制

大部分网站需要用户名和密码才能登陆，这其实是一种安全机制;对应的服务也可以使用这一机制，不是谁都可以调用，调用服务前必须先申请开通一个唯一的appid，提供相关的密钥，在调用接口时需要提供appid+密钥信息，服务端会进行验证。

appid使用字母，数字，特殊符号等随机生成，生成的唯一appid看系统实际要求是否需要全局唯一;不管是否全局唯一最好有以下属性：

趋势递增: 这样在保存数据库的时候，索引的性能更好

信息安全: 随机生成，不要是连续的，容易被发现规律

关于全局唯一Id生成的方式常见的有snowflake方式等

snowflake
 

时间戳机制

数据经过了加密处理，酒店抓取到了数据也看不到真实数据;但是有不法者不关心真实数据，拿到数据后直接进行恶意请求，这个时候简单的做法可以考虑时间戳机制，在每次请求中加入当前时间，服务端会将报文中的时间与系统当前时间做比对，看是否在一个固定的时间范围内比如5分钟，恶意伪造的数据是没法更改报文中时间的，超过5分钟就可以当作非法请求了。

伪代码如下：

（编辑：长春站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!