pick王菊？作为“菊外人”的程序员能做点什么？

最近，想必大家的朋友圈都被“王菊”占领了，打开朋友圈到处可以见到“pick王菊”、“陶渊明”、“菊外人”等字眼，可谓是火的一塌糊涂。

作为一个“菊外人”的我“跟风”的去了解了一下到底是怎么回事儿。原来是最近很火的一个选秀节目，大家都在呼吁给一个叫“王菊”的人投票。然后就有各种媒体发文分析“到底王菊是谁？”、“王菊为什么火了？”、“pick王菊给这个社会带来了什么？”等等文章。

但是，作为一个程序员，我们看这个世界的角度永远是那么的独特：

我们是那个浏览网页的时候经常会按ctrl + s的人。

我们是那个按下电梯的之后就会忍不住想电梯调度算法的人。

我们是那个每次支付宝付款的时候都会考虑二维码的生成逻辑的人。

不管是作为“菊外人”还是“陶渊明”，对于这个“pick王菊”事件，我们的角度是：如何实现一个高并发的投票系统？

我们需要一个怎样的投票系统？笔者分别浏览了目前创造101的各个投票通道，基本的要求有以下几个：

1、只有登录用户能投票

2、每个用户投票数有限

3、不同用户可投票数不同，如Vip会比普通用户的票数多

4、投票是限时的，只有在有效时段内才能投票

除了以上几个功能性要求外，作为一个开发人员，还需要考虑以下几个非功能性需求：

1、计数要准确

2、可以处理高并发投票

3、可以处理大量的投票数据

4、要有很好的可用性

5、要把每个人的投票记录下来

登录验证

投票网站都是需要登录验证的，用户想要进行投票，需要先登录。目前很多大型网站的登录都采用单点登录（SSO，Single Sign On）技术，SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它是目前比较流行的企业业务整合的解决方案之一。

实现SSO的技术主要有以下几种：

(1）基于cookies实现。 最简单的单点登录实现方式，是使用cookie作为媒介，存放用户凭证。但是存在几个问题；1、cookies并不安全，2、cookies本身不跨域。3、浏览器对cookies个数和大小有限制。但是，如果想要解决的话，以上三个问题还是可以找到方案的。只不过会让整个方案变得复杂而已。

(2)  Broker-based（基于经纪人），例如Kerberos等；这种技术的特点就是，有一个集中的认证和用户帐号管理的服务器。经纪人给被用于进一步请求的电子的身份存取。中央数据库的使用减少了管理的代价，并为认证提供一个公共和独立的"第三方"。例如Kerberos,Sesame,IBM KryptoKnight（凭证库思想)等。Kerberos是由麻省理工大学发明的安全认证服务，当前版本V5，已经被UNIX和Windows作为默认的安全认证服务集成进操作系统。

(3)  Agent-based（基于代理人）在这种解决方案中，有一个自动地为不同的应用程序认证用户身份的代理程序。这个代理程序需要设计有不同的功能。比如，它可以使用口令表或加密密钥来自动地将认证的负担从用户移开。代理人被放在服务器上面，在服务器的认证系统和客户端认证方法之间充当一个"翻译"。例如SSH等。

(4)  Token-based，例如SecurID,WebID，现在被广泛使用的口令认证，比如FTP,邮件服务器的登录认证，这是一种简单易用的方式，实现一个口令在多种应用当中使用。

(5)  基于安全断言标记语言（SAML）实现，SAML(Security Assertion Markup Language，安全断言标记语言）的出现大大简化了SSO，并被OASIS批准为SSO的执行标准。开源组织OpenSAML 实现了 SAML 规范。可参考。

目前，很多大型网站都采用一个开源的SSO解决方案——CAS，CAS由耶鲁大学开发的单点登录系统（SSO,single sign-on），应用广泛，具有独立于平台的，易于理解，支持代理功能。

权限控制

在投票网站验证完用户的登录信息之后，紧接着会判断用户的权限，然后根据不同的权限来给用户分配不同的可投票次数。

关于权限的设计，一直是很多网站都要关心的问题。几乎所有的网站都会有一定的权限要求。

目前，关于权限设计大部分均采用RBAC理论（Role-Based Access Control），即基于角色的权限访问控制。

RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，Who、What、How构成了访问权限三元组,也就是“Who对What进行How的操作”。

一个简单的权限系统应该包含以下几个基本元素：

用户、角色、权限、资源、操作。

【用户】可以属于多个【角色】。【角色】可以认为是【权限】的合集。【权限】描述的是对【资源】的可【操作】能力。