2、你思考过共享单车背后的技术点么？比如说数据库、移动应用开发、定位、通信？如何串联？
从业务流程上说，这是一个典型的互联网O2O场景:车(GPS, bluetooth, 智能硬件) <-> 用户端(Mobile APP) <-> Cloud Server (App/Middleware 接口和数据库)这是一个千万级的终端容量，连结用户、车辆，管理平台进行实时处理效率要求非常高，需制定可靠、高效的网络方案。另外借助于大数据技术, 引入新的人工智能平台(摩拜”魔方”), 提供精准化管理和决策支持。显然从技术加持的角度，目前摩拜作的更好一些。
3、3月初，摩拜单车发生过数据库宕机事件，为避免事件再次发生，有何战略性建议？
宕机事件的频繁暴发, 如果是自然业务增长导致的系统瓶颈，如后台服务器过载故障，很容易通过横向的增加服务器来解决。对于传统的关系型数据库, 一般采用 Scale-Out 架构。 现今大多互联网选择 Cloud 数据库服务, 提供多种类型如 RDB，内存数据库, 分布式数据库等等，可弹性使用。
4、在竞争如此激烈的市场，如何做到脱颖而出，更加便利服务大众，你有何想法？
ofo 与 摩拜, 同 oracle 与 db2, 应该增加合作, 取长补短。有时候”简单粗暴”未必效果不好.从业务角度来说: 优化业务流程, 减少成本 从技术角度来说:后端应用架构的技术, 后端代码质量, 基础设施优化是一个不断迭代的过程, 随着时间、业务、用户的变化而不断地更新和维护从运维角度说: 监控和跟踪后台数据请求，跟踪基础设施状态等及时发现, 另外智能分析, 从前到后,从上到下各层次环节关联在一起进行分析，找出性能瓶颈及其原因
一个好的技术团队, 运营团队, 运维团队对于创新的互联网公司缺一不可.
hai503：
1、你经常骑共享单车么？都骑过哪些？在使用上，你觉得哪个更便利？
怎么能没骑过？！摩拜、ofo，主要是这两个。摩拜的定位和预约，让用车更方便，尽管定位不准确是永远的痛，如果你在街上看到有人拿着手机在找东西，那八成就是找不到摩拜单车……
2、你思考过共享单车背后的技术点么？比如说数据库、移动应用开发、定位、通信？如何串联？
车辆的调配和移动，要基于用户的习惯（常用路线）和重大集体活动来决策，背后的数据清洗、分析，需要大数据技术的支持。
3、3月初，摩拜单车发生过数据库宕机事件，为避免事件再次发生，有何战略性建议？
业务数据库建议分片，即使某个实例down掉，不至于所有业务停摆。
4、在竞争如此激烈的市场，如何做到脱颖而出，更加便利服务大众，你有何想法？
从一个用户的角度来说，就目前我个人的体验，ofo最早的一批单车，是最好骑的——轻便，后来出的“小”黄车，骑起来比摩拜的Lite还费力。在市场已经打开的情况下，提升用户使用感受，应该是突破点。BTW，单车的烧钱时代来了，借着这股东风，大家骑行起来吧！~~
Xdsnet：
1、你经常骑共享单车么？都骑过哪些？在使用上，你觉得哪个更便利？
经常骑，主要是摩拜和ofo，使用上觉得摩拜的更便利。
2、你思考过共享单车背后的技术点么？比如说数据库、移动应用开发、定位、通信？如何串联？
简单思考过
关于数据库，其实涉及几个不同的库，一个是自行车信息库，一个是用户使用方面的库，自行车库的重点是适当时候更新位置信息和状态（是否锁定），可能的话还有设备健康度信息（通过自检完成）用户使用方面的库涉及金融数据操作等
对于移动开发，其实其主要为一个地理信息系统（类似地图应用）增加计时、计费、解锁硬件等等扩展
关于定位：涉及两个方面的定位，其一是自行车设备本身的定位，其二是app定位，自行车本身定位不同的技术路线不尽相同，之所以个人觉得摩拜更方便，就是其所有的车内置了定位通讯，在每次锁闭时更新定位信息（这样更节约电）app定位就没有多大说的了
通信：主要的难点在于自行车的通信，要考虑快捷、长期可用的节点等等因素，技术应该和移动通讯公司合作（不用单独布网了）
串联：不理解楼主所指
3、3月初，摩拜单车发生过数据库宕机事件，为避免事件再次发生，有何战略性建议？
对于这一事件，其实建议应该是比较通用常见的，就是增加系统冗余，通过多活、灾备等等软硬件投入增加基础环境的抗风险能力，通过加强技术巡查等相关技术、制度建设投入进一步减少事故发生。