本文目录一览：
如何设计一个秒杀系统
1） 对现有网站业务的冲击
因为秒杀活动只是网站营销的一个附加活动，这个活动具有时间短，并发访问量大的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。
2） 高并发情况以及数据库的负载
用户在秒杀开始前，通过不停的刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器、数据库服务器造成极大的负载压力。
3） 突然增加的网络和服务器带宽
假设商品页面大小200K（主要是商品图片大小），那么需要的网络和服务器带宽是2G（200K×10,000），这些网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽。
4） 直接下单
秒杀的游戏规则是到了秒杀时间才能开始对商品下单购买，在此时间点之前，只能浏览商品信息，不能下单。而下单页面也是一个普通的URL，如果得到这个URL，不用等到秒杀开始就可以下单了。
5） 防止机器秒杀
防止网上的一些“秒杀器”
针对上面的5个问题，对应的策略如下：
1） 秒杀系统独立部署
为了避免因为秒杀活动的高并发访问而拖垮整个网站，使整个网站不必面对蜂拥而来的用户访问，将秒杀系统独立部署，如果需要，还可以使用独立的域名，以和网站完全隔离，即使秒杀系统崩溃了，也不会对网站造成任何影响。
秒杀系统架构如何设计
这种高频系统需要考虑的因素很多。
如果在一分钟内会有上百万次请求， 那么1秒钟就要处理1万多次请求。 那么我们分析一下延迟：
网络延迟
系统IO延迟
内存延迟
缓存延迟
数据库延迟
对于网络延迟，没有很好的解决方法，这个跟用户的网络环境有关
对于系统IO， 不太推荐用多线程以及线程池模型。 多线程创建销毁都会有很大的额外开销， 线程池会有等待延迟。 推荐使用libevent这类多路io的框架， 可以在一个线程内完成IO非常轻量
对于内存延迟， 如果我们在短时间内要做大量的业务，建议使用slab这类内存对象方式分配内存，这样可以减少内存分配器带来的开销。 处理完的业务可以放在队列中，可以单独设计一个线程处理队列来给用户response（response延迟并不是那么重要）。另外有大量优化的地方， 例如排除cpu缓存伪共享，集成第三方高性能内存分配器等等手段， 如果有需求可以研究一下。
一般秒杀系统session数据会放在缓存中，例如redis。 如果请求多了， 那么流量会全部压到一个redis的server上，会造成轻微延迟（redis是单线程队列）， 这时候可能需要做一个主从系统，不过公司的硬件环境不好有可能会有反效果， 一般情况下1s处理几万次请求还是没有多大问题的。
数据库不要动态写，肯定慢，秒杀结束后一次性把redis的transactions 同步进去。
处理IO建议不要直接用后台服务器， 建议做几个io服务器和客户端连接， 接到客户端请求后用rpc框架投到你的后台。 一个电脑的socket多了后性能下降很快。
java秒杀系统如何实现
如果是jsp登录PHP 那就模拟一个PHP登录的post提交到php的登录程序。 如果php登录jsp 那就模拟jsp登录的post提交到jsp的登录程序
哪里有java视频教程？求推荐。
java视频教程网站：Codecademy、慕课网和实验楼。
1、Codecademy：
Codecademy是一家国外知名的在线学习编程的网站，世界各地的人都在上面学习编程，虽然是全英文的，但是大多数单词都比较通熟易懂，在学习编程的同时，也可以提高我们的英语阅读能力，遇到实在不认识的单词，可以用谷歌翻译一下。Codecademy会根据你的爱好和目前水平，给你推荐合适的课程，我感觉还挺不错的。
2、慕课网：
慕课网是垂直的互联网IT技能免费学习网站。我认为是目前国内最好的编程类学习网站，资源十分丰富，以独家视频教程为特色，学习成本较低。慕课网上几乎涵盖了目前所有主流技术的教程。
3、实验楼：
实验楼是以实验为核心的IT在线教育网站，网站为IT学习者提供实践操作实验环境和全面的IT课程。这是一家格外注重实践操作的网站，这也是它的特色所在，里面设置了各种楼赛，进行挑战升级，学习成本较低，学习效率较高。
Redis 秒杀系统的设计与实现
还记得刚工作那会，每每听到大牛们聊技术，各种专业术语，巴拉巴拉的，简直像是在听天书，比如什么中间件、分布式、SOA、无状态、热更新、懒加载、ACID、LVS、LDAP、VIP、CDN、负载均衡、鲁棒性、POJO、DSL、DI、IOC，太多太多了。一转眼快 10 年过去了，当很多新人再问到我这些名词的时候，我就在想，能不能用通俗易懂的大白话，就能聊明白这些专业的技术知识呢？
最近，给几个公司做技术咨询，经常会聊到秒杀系统。所以，借这次机会，尝试用大白话和大家聊聊 Redis 秒杀系统的设计与实现，。
说起 “秒杀”，我相信大家肯定都耳熟能详了，双十一零点抢购、手机整点抢购、抢火车票、1 元秒杀、抢红包等等，都可以说是秒杀的各种应用场景了。
秒杀系统的设计 ，难就难在，在极短的时间内，应对瞬时涌入平时成百上千倍的巨大流量，还包括各种攻击刷量作弊等未知流量，最终我们要保证在用户体验顺畅良好的情况下，不能多卖或者少卖。
而当我们公司决定要做秒杀系统的时候，我就去找业务，到时大概会有多少 UV，不知道 10 倍或者 100 倍？然后去找老板，给技术多少预算，最多平时的 10 倍不能再多了，当然越少越好，呵呵，也就是说让我们用平时最多 10 倍的预算去解决不可预估的用户流量，怎么做？要是有钱直接扔 1 万台服务器跑去吧，钱能解决的事就不是事，但问题是现在还没那么多钱，还要把事情搞定。
在聊秒杀系统设计之前，让我们先回到现实生活中，聊聊常见的“秒杀”场景和秒杀场景的独有特点，以及它们都是怎么应对的，在应对过程中都需要注意什么。
日常生活中，其实也有很多秒杀场景，比如，早上 9 点超市开门，老大爷老大妈抢购蔬菜水果，是不是？ 还有，新楼盘开盘抢购，是不是？ 股市开盘、交易所现场，是不是？
对的，生活中其实有太多类似场景了， 你有没有发现“秒杀”的独有特点呢？
记住了上面三个特点，我们就可以区分和确定秒杀的业务场景了。 这里我举一个特别的例子， 你说挤公交车，算不算秒杀场景呢？
下面，我再和大家聊一个关于抢猪肉的故事。
在保安部门充分讨论之后，保安大队长决定通过以下安排，在保证人员安全的前提下，还要做到相对公平。
后来，活动井然有序的开始了，但是由于猪肉销售场地太远，销售窗口又少，老大爷和老大妈们买肉又精挑细选，导致整个过程很漫长，而且外面等候的人们都开始骚动起来，这个时候保安大队长赶紧找到经理：
故事讲完了，如果我们把上面的故事，理解为秒杀业务场景，我们就可以总结出一个 秒杀系统的设计原则 了：
