Zakelly commented on code in PR #26312:
URL: https://github.com/apache/flink/pull/26312#discussion_r2020517479
##
docs/content.zh/docs/dev/datastream/fault-tolerance/state_v2.md:
##
@@ -25,40 +25,25 @@ specific language governing permissions and limitations
under the License.
-->
-# Working with State V2 (New APIs)
+# 使用 State V2 (New APIs)
+本章节您将了解 Flink 用于编写有状态程序的新 API，要了解有状态流处理背后的概念，请参阅[Stateful Stream
+Processing]({{< ref "docs/concepts/stateful-stream-processing" >}})。
-In this section you will learn about the new APIs that Flink provides for
writing
-stateful programs. Please take a look at [Stateful Stream
-Processing]({{< ref "docs/concepts/stateful-stream-processing" >}})
-to learn about the concepts behind stateful stream processing.
-
-The new state API is designed to be more flexible than the previous API. User
can perform
-asynchronous state operations, thus making it more powerful and more efficient.
-The asynchronous state access is essential for the state backend to be able to
handle
-large state sizes and to be able to spill to remote file systems when
necessary.
-This is called the 'disaggregated state management'. For more information
about this,
-please see [Disaggregated State Management]({{< ref
"docs/ops/state/disaggregated_state" >}}).
+新的 state API 比以前的 API 更灵活，用户可以通过新的 API 使用异步状态操作，这使得新的 API 更加强大有效。
Review Comment:
```suggestion
新的 state API 比以前的 API 更灵活，用户可以通过新的 API 使用异步状态操作，是一套更强大有效的 API。
```
##
docs/content.zh/docs/dev/datastream/fault-tolerance/state_v2.md:
##
@@ -25,40 +25,25 @@ specific language governing permissions and limitations
under the License.
-->
-# Working with State V2 (New APIs)
+# 使用 State V2 (New APIs)
+本章节您将了解 Flink 用于编写有状态程序的新 API，要了解有状态流处理背后的概念，请参阅[Stateful Stream
+Processing]({{< ref "docs/concepts/stateful-stream-processing" >}})。
-In this section you will learn about the new APIs that Flink provides for
writing
-stateful programs. Please take a look at [Stateful Stream
-Processing]({{< ref "docs/concepts/stateful-stream-processing" >}})
-to learn about the concepts behind stateful stream processing.
-
-The new state API is designed to be more flexible than the previous API. User
can perform
-asynchronous state operations, thus making it more powerful and more efficient.
-The asynchronous state access is essential for the state backend to be able to
handle
-large state sizes and to be able to spill to remote file systems when
necessary.
-This is called the 'disaggregated state management'. For more information
about this,
-please see [Disaggregated State Management]({{< ref
"docs/ops/state/disaggregated_state" >}}).
+新的 state API 比以前的 API 更灵活，用户可以通过新的 API 使用异步状态操作，这使得新的 API 更加强大有效。
+异步 state 访问对“存算分离”来说是必要的，即令状态后端支持大状态和在必要时将文件溢出到远程文件系统的能力。更多关于
Review Comment:
```suggestion
异步 state 访问对存算分离来说是必要的，即令状态后端支持大状态时将文件溢出到远程文件系统的能力。更多关于
```
##
docs/content.zh/docs/dev/datastream/fault-tolerance/state_v2.md:
##
@@ -275,62 +218,42 @@ env.fromElements(Tuple2.of(1L, 3L), Tuple2.of(1L, 5L),
Tuple2.of(1L, 7L), Tuple2
{{< /tab >}}
{{< /tabs >}}
-This example implements a poor man's counting window. We key the tuples by the
first field
-(in the example all have the same key `1`). The function stores the count and
a running sum in
-a `ValueState`. Once the count reaches 2 it will emit the average and clear
the state so that
-we start over from `0`. Note that this would keep a different state value for
each different input
-key if we had tuples with different values in the first field.
-
-### Execution Order
-
-The state access methods are executed asynchronously. This means that the
state access methods
-will not block the current thread. With synchronous APIs, the state access
methods will be executed in
-the order they are called. However, with asynchronous APIs, the state access
methods will be executed
-out of order, especially for those invokes for different incoming elements.
For the above example,
-if the `flatMap` function is invoked for two different incoming elements A and
B, the state access
-methods for A and B will be executed. Firstly, `asyncGet` is executed for A,
then `asyncGet` is
-allowed to execute for B. The finish order of the two `asyncGet` is not
guaranteed. Thus the order
-of continuation of the two `StateFuture`s is not guaranteed. Thus invokes of
`asyncClear` or
-`asyncUpdate`for A and B are not determined.
-
-Although the state access methods are executed out of order, this not mean
that all the user code
-are run in parallel. The user code in the `processElement`, `flatMap` or
`thenXXxx` methods
-following the state access methods will be executed in a single thread (the
task thread). So there
-is no concurrency issue for the user code.
-
-Typically, you don't need to worry about the execution order of the state
access methods, but there
-is still some rules the Flink will ensure:
-* The execution order of user code entry `fl
