Goodbug提出的：
全国一盘棋。每天1000车次，每车次简化就20段，每车三种票，卧铺，硬座，站票，每
种1000张。上下铺什么的我就不跟你计较了。联票也是支持最多两张
就好，或者说一次转车。用户自选，也不用你算什么最短路径。但是每个车次的票号得
一样。
反正不能重票，错票。不能有票不出。高峰的时候必须能对99.9%的请求在30秒内作出
响应并出票。
qxc提出的协议
协议：
4 bytes transactionId
2 bytes trainId1
1 byte seatType
1 byte start1
1 byte end1
2 bytes trainId2
1 byte start2
1 byte end2
我的修改建议：
加上trainid2, start2, end2。因为goodbug要联票转车。
当然，联票转车要算出两张票才对。碰到联票，transaction算2个。
trainid是0表示不转车。
返回 {
4 bytes transactionId
1 byte isSuccess
}
那我们就上单机， 不断电， 只看看 perf.
我的增强版：
实时异步写盘。只要不断电，保证log都写到SSD盘上。
这个完全goodbug的条件。但是他要求实施优化车票分配。这样性能要打点折扣。因此
我提议性能定在1MM TPS，向5MM TPS努力。Goodbug接受了。
各位有意见么？
这是内部服务器：
1. transactionid要做到global unique。
2. 假定security有人管。我不负责安全性检查
3. 不限制同时连接的client，但是client要保证unique transactionid。
4. CLient要有礼貌，尽量pool message into same IP packet, DO NOT use TCP_
NODELAY。不能频繁连接断开。
5. Client如果断开，未发出的response将丢弃。但是买到的票依然保留。可以在
logfile中查到。
6. 这是简化实现，尽量测试核心性能。其他的技术要求（可靠性，信息一致，管理性
，商业逻辑）均可实现，对核心性能没有根本影响。请大家自重，尊重理论，不要用任
何不合理feature要求混淆是非。
