在线事务处理一般可分为在线交易事务处理（OLTP）和在线分析事务处理（OLAP），也有叫联机交易处理和联机分析处理。而混合型事务处理（HTAP）则融合了上述两种事务类型，即一个系统同时很好的满足OLTP和OLAP的需求。
早在2014年Gartner的报告就明确指出了：“混合型交易/分析事务处理（HTAP）将帮助应用提升场景识别能力，增强业务敏捷性。这将引发由内存计算技术催生的现有架构和IT科技的剧变”。
电子商务领域就有很多混合型事务处理的例子，比如信用卡消费，既要计算当前消费，又要按T+1统计剩余额度；个性化引擎，既要应对当下行为，又要根据偏差调整推荐算法；物联网事件处理器等等。
当然作为这样一套系统，首先它需要满足一些非功能的需求，包括每秒10万次以上的并发处理能力；可以与应用同步线性扩展；零网络延时、零数据丢失。在功能性上，它需要支持纯Java技术栈的业务逻辑以及可以接受来自流处理框架（[【观察】常用的流式框架（一）-- Storm与Samza](https://yq.aliyun.com/articles/750868?spm=a2c4e.11155435.0.0.409a33129XlKTs)；[【观察】常用的流式框架（二）-- Spark与Flink](https://yq.aliyun.com/articles/750869?spm=a2c4e.11155435.0.0.409a33129XlKTs)）的消息，并能对其中的状态信息进行快速识别。
上图的模型是最早的OLTP与OLAP并存模型，没有任何的分离处理，直接面临的问题就是中间关系型数据库在承载多分析模块读取数据的同时，源应用程序的写操作会处理不过来。于是企业的数据架构又会在应用与结构化数据库之间加入一层操作性数据库（ODS）。
ODS确实很好的分解了OLTP与OLAP的资源分配，但是首先会带来数据冗余，其次由于ETL转置需要时间，因此数据仓库中的数据距离实时性一定会有不小的差距，进而就导致报表数据的不及时。并且ETL任意环节的故障都会导致数据仓库的失真。
随着内存计算技术的发展，并且借助多版本并发控制（MVCC）能力，HTAP已经可以将OLTP和OLAP事务放在一个数据库上处理了。
这类数据库市面上的选择还不少，尤以VoltDB，NuoDB和MemSQL为首，程序内置MVCC功能可以对频繁更新的数据记录版本号，以建立缓存序列供OLAP差异化调取。
随着微服务在企业中的普及，不同的微服务可以挂接不同的HTAP数据库以满足多并发更新与读取的需求。当然如果目标微服务没有很大的并发更新量的情况下，多个微服务共享一个HTAP，根据Schema分库分表也不失为企业混合事务处理的有效解决办法。
