这题难点在于Schema太多了， 分布式的时候到底怎么sharding。。
Scenario
用户搜索
用户reserve
用户付款
商家上新
Api:
Search(location, time, keyword), 返回一组show， JSON格式
GetSeat(showId)， 返回ListOfAvailableSeat,
Reserve(showId, List
AddShow(cinimaId, time, showInfo)
Work Flow
用户通过load balancer 连结某个服务器，用户搜索，服务器返回一组比如说十个show，每个show也显示场次信息（有无余票)
用户选择某个show, pull出更详细的信息和座位列表。
用户选择一些座位，reserve。
如果reserve成功，转入付款页面。
数据库设计
Cinema Table: 读多写基本没有。
CinemaId, CinemaName, City, Zip, Address
CinemaHall Table: 读多写基本没有
hallId, cinemaId, capcity
Movie Table 读多写少， 基本不改
MovieId, MovieName, Description, Length
Movie Category Table 读多写少， 基本不改
MovieId, Category
Show Table 读多写少， 要经常改
ShowId, MovieId, HallId, StartTime, EndTime, RemainingTickets
Seat Table: 读多写少，基本不改。
HallId, SeatId, class, Row, Col
ShowSeat Table 要经常改
ShowId, SeatId, Status, BookingId
Booking Table 要经常写
BookingId, CustomerId, timeStamp, status(paid, pending, canceld), amount
CustomerTable 要经常写
UserId, user name, passWord, lastLogin,
Detailed Work Flow
通过Zip code查Cinema, 然后join CinemaHall Table查哪些Hall, 通过HallId 去查最近放什么电影， 时间各是什么时候。然后查找那些category相关的电影，时间match的上的电影。返回 一个List
用户选了某个Movie + Show time, 系统会把这个show time的 各种Seat 并显示出来。 List
系统其实是拿着这个showId去showSeat Table里找那些空余的seat
用户选择某些Seats 来 reserve: reserve(List
如果这些Seat还在，系统会把这个seat标记为pending, 并引导用户进入付款页面。 如果5分钟后这些Seat还在pending，则这些Seat又会标记成available。
如果说没有availabe的位置，但有pending的位置，则用户进入排队页面。一旦有别的票释放出来，就给优先级最高的人。
如何优化查询：
Cinema Table 按Zip建index, 按city建index。
CinemaHallTable按CinemaId建index
Show Table 按MovieId建index, 按hallIId 建index
ShowSeatTable按showId建index，
如何Scale
Cinema Table按城市sharding, CimenaHall table按cinemaId sharding, 其实这两个表都不用sharding, 因为他们本来可能就内容少，而且基本不改。
Movie Table 按MovieId sharding, Show Table按HallId Sharding, SeatTable 按HallId sharding, ShowSeat Table按ShowId sharding。Booking Table按 CustomerId Sharding,
Consistent hashing。