小言_互联网的博客

linux C/C++服务器后台开发面试题总结(系统架构篇)

361人阅读  评论(0)

1.设计一个服务,提供递增的SessionID服务,要求保证服务的高可靠性,有哪些方案?集中式/非集中式/分布式

2.多台服务器要执行计划任务,但只有拿到锁的任务才能执行,有一个中心服务器来负责分配锁,但要保证服务的高可靠性。

3.如何有效的判断服务器是否存活?服务器是否踢出集群的决策如何产生?

4.两个服务器如何在同一时刻获取同一数据的时候保证只有一个服务器能访问到数据?

可以采用队列进行处理,写一个队列接口保证同一时间只有一个进程能够访问到数据,或者对于存取数据库的来说,数据库也是可以加锁处理的

  1. 编写高效服务器程序,需要考虑的因素

性能对服务器程序来说是至关重要的了,毕竟每个客户都期望自己的请求能够快速的得到响应并处理。那么影响服务器性能的首要因素应该是:

(1)系统的硬件资源,比如说CPU个数,速度,内存大小等。不过由于硬件技术的飞速发展,现代服务器都不缺乏硬件资源。因此,需要考虑的主要问题是如何从“软环境”来提升服务器的性能。

服务器的”软环境“

(2)一方面是指系统的软件资源,比如操作系统允许用户打开的最大文件描述符数量

(3)另一方面指的就是服务器程序本身,即如何从编程的角度来确保服务器的性能。

主要就要考虑大量并发的处理这涉及到使用进程池或线程池实现高效的并发模式(半同步/半异步和领导者/追随者模式),以及高效的逻辑处理方式–有限状态机内存的规划使用比如使用内存池,以空间换时间,被事先创建好,避免动态分配,减少了服务器对内核的访问频率,数据的复制,服务器程序还应该避免不必要的数据复制,尤其是当数据复制发生在用户空间和内核空间之间时。如果内核可以直接处理从socket或者文件读入的数据,则应用程序就没必要将这些数据从内核缓冲区拷贝到应用程序缓冲区中。这里所谓的“直接处理”,是指应用程序不关心这些数据的具体内容是什么,不需要对它们作任何分析。比如说ftp服务器,当客户请求一个文件时,服务器只需要检测目标文件是否存在,以及是否有权限读取就可以了,不需要知道这个文件的具体内容,这样的话ftp服务器就不需要把目标文件读入应用程序缓冲区然后调用send函数来发送,而是直接使用“零拷贝”函数sendfile直接将其发送给客户端。另外,用户代码空间的数据赋值也应该尽可能的避免复制。当两个工作进程之间需要传递大量的数据时,我们就应该考虑使用共享内存来在他们直接直接共享这些数据,而不是使用管道或者消息队列来传递。上下文切换和锁:并发程序必须考虑上下文的切换问题,即进程切换或线程切换所导致的系统开销。即时I/O密集型服务器也不应该使用过多的工作线程(或工作进程),否则进程间切换将占用大量的CPU时间,服务器真正处理业务逻辑的CPU时间比重就下降了。因此为每个客户连接都创建一个工作线程是不可取的。应该使用某种高效的并发模式。(半同步半异步或者说领导者追随者模式)另一个问题就是共享资源的加锁保护。锁通常被认为是导致服务器效率低下的一个因素,因为由他引入的代码不仅不处理业务逻辑,而且需要访问内核资源,因此如果服务器有更好的解决方案,应该尽量避免使用锁。或者说服务器一定非要使用锁的话,尽量使用细粒度的锁,比如读写锁,当工作线程都只读一块内存区域时,读写锁不会增加系统开销,而只有当需要写时才真正需要锁住这块内存区域。对于高峰和低峰的伸缩处理,适度的缓存。

  1. QQ飞车新用户注册时,如何判断新注册名字是否已存在?(数量级:几亿)

可以试下先将用户名通过编码方式转换,如转换64位整型。然后设置N个区间,每个区间为2^64/N的大小。对于新的用户名,先通过2分寻找该用户名属于哪个区间,然后在在这个区间,做一个hash。对于不同的时间复杂度和内存要求可以设置不同N的大小~

加一些基础的技术面试之外的职业素养的面试问题

1.你在工作中犯了个错误,有同事打你小报告,你如何处理?

a.同事之间应该培养和形成良好的同事关系,就是要互相支持而不是互相拆台,互相学习,互相帮助,共同进步。

b.如果小报告里边的事情都是事实也就是说确实是本人做的不好不对的方面,那么自己应该有则改之,提高自己。如果小报告里边的事

情全部不是事实,就是说确实诬陷,那么应该首先坚持日久见人心的态度,持之以恒的把本职工作做好,然后在必要的时候通过适当的

方式和领导沟通,相信领导会知道的。

2.你和同事合作完成一个任务,结果任务错过了截止日期,你如何处理?

3.职业规划?

4.离职原因?

  1. 项目中遇到的难题,你是如何解决的?

A.时间 b要求 c.方法


转载:https://blog.csdn.net/lingshengxueyuan/article/details/100926261
查看评论
* 以上用户言论只代表其个人观点,不代表本网站的观点或立场